Re: 2.4.7-pre9..
On Thu, Jul 19 2001, Linus Torvalds wrote:
>
> I'm getting ready to do a 2.4.7, but one of the fixes in 2.4.7 is a nasty
> SMP race that was found and made it clear that using an old trick of
> having a semaphore on the stack and doing "down()" on it to wait for some
> event (that would do the "up()") was a really bad idea.
Attached are two patches -- one that should fix DAC960 for this new
completion scheme, and one that corrects the corrected comment in
blkdev.h :-)
--
Jens Axboe
--- linux/drivers/block/DAC960.c~ Fri Jul 20 09:18:43 2001
+++ linux/drivers/block/DAC960.cFri Jul 20 09:18:44 2001
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -484,14 +485,14 @@
static void DAC960_ExecuteCommand(DAC960_Command_T *Command)
{
DAC960_Controller_T *Controller = Command->Controller;
- DECLARE_MUTEX_LOCKED(Semaphore);
+ DECLARE_COMPLETION(Wait);
unsigned long ProcessorFlags;
- Command->Semaphore = &Semaphore;
+ Command->Waiting = &Wait;
DAC960_AcquireControllerLock(Controller, &ProcessorFlags);
DAC960_QueueCommand(Command);
DAC960_ReleaseControllerLock(Controller, &ProcessorFlags);
if (in_interrupt()) return;
- down(&Semaphore);
+ wait_for_completion(&Wait);
}
@@ -1316,7 +1317,7 @@
*Controller)
{
DAC960_V1_DCDB_T DCDBs[DAC960_V1_MaxChannels], *DCDB;
- Semaphore_T Semaphores[DAC960_V1_MaxChannels], *Semaphore;
+ Completion_T Wait[DAC960_V1_MaxChannels], *wait;
unsigned long ProcessorFlags;
int Channel, TargetID;
for (TargetID = 0; TargetID < Controller->Targets; TargetID++)
@@ -1327,12 +1328,12 @@
DAC960_SCSI_Inquiry_T *InquiryStandardData =
&Controller->V1.InquiryStandardData[Channel][TargetID];
InquiryStandardData->PeripheralDeviceType = 0x1F;
- Semaphore = &Semaphores[Channel];
- init_MUTEX_LOCKED(Semaphore);
+ wait = &Wait[Channel];
+ init_completion(wait);
DCDB = &DCDBs[Channel];
DAC960_V1_ClearCommand(Command);
Command->CommandType = DAC960_ImmediateCommand;
- Command->Semaphore = Semaphore;
+ Command->Waiting = wait;
Command->V1.CommandMailbox.Type3.CommandOpcode = DAC960_V1_DCDB;
Command->V1.CommandMailbox.Type3.BusAddress = Virtual_to_Bus32(DCDB);
DCDB->Channel = Channel;
@@ -1363,11 +1364,11 @@
DAC960_SCSI_Inquiry_UnitSerialNumber_T *InquiryUnitSerialNumber =
&Controller->V1.InquiryUnitSerialNumber[Channel][TargetID];
InquiryUnitSerialNumber->PeripheralDeviceType = 0x1F;
- Semaphore = &Semaphores[Channel];
- down(Semaphore);
+ wait = &Wait[Channel];
+ wait_for_completion(wait);
if (Command->V1.CommandStatus != DAC960_V1_NormalCompletion)
continue;
- Command->Semaphore = Semaphore;
+ Command->Waiting = wait;
DCDB = &DCDBs[Channel];
DCDB->TransferLength = sizeof(DAC960_SCSI_Inquiry_UnitSerialNumber_T);
DCDB->BusAddress = Virtual_to_Bus32(InquiryUnitSerialNumber);
@@ -1381,7 +1382,7 @@
DAC960_AcquireControllerLock(Controller, &ProcessorFlags);
DAC960_QueueCommand(Command);
DAC960_ReleaseControllerLock(Controller, &ProcessorFlags);
- down(Semaphore);
+ wait_for_completion(wait);
}
}
return true;
@@ -2768,7 +2769,7 @@
if (Request->cmd == READ)
Command->CommandType = DAC960_ReadCommand;
else Command->CommandType = DAC960_WriteCommand;
- Command->Semaphore = Request->sem;
+ Command->Waiting = Request->waiting;
Command->LogicalDriveNumber = DAC960_LogicalDriveNumber(Request->rq_dev);
Command->BlockNumber =
Request->sector
@@ -2924,10 +2925,10 @@
/*
Wake up requestor for swap file paging requests.
*/
- if (Command->Semaphore != NULL)
+ if (Command->Waiting)
{
- up(Command->Semaphore);
- Command->Semaphore = NULL;
+ complete(Command->Waiting);
+ Command->Waiting = NULL;
}
add_blkdev_randomness(DAC960_MAJOR + Controller->ControllerNumber);
}
@@ -2969,13 +2970,10 @@
DAC960_ProcessCompletedBuffer(BufferHeader, false);
BufferHeader = NextBufferHeader;
}
- /*
- Wake up requestor for swap file paging requests.
- */
- if (Command->Semaphore != NULL)
+ if (Command->Waiting)
{
- up(Command->Semaphore);
- Command->Semaphore = NULL;
+ complete(Command->Waiting);
+ Command->Waiting = NULL;
}
}
}
@@ -3589,8 +3587,8 @@
}
if (CommandType == DAC960_ImmediateCommand)
{
- up(Command->Semaphore);
- Command->Semaphore = NULL;
+ complete(Command->Waiting);
+ Command->Waiting = NULL;
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
On Tue, Jul 17, 2001 at 08:58:32PM -0700, David S. Miller wrote: > Initially we believed it might be some obscure bug in netfilter > which got triggered more easily when the zerocopy stuff went in. > But all of our code audits turned up nothing. > > Then I began to notice that "pppoe" was showing up in all the reports > where the user actually bothered to mention what net devices the > machine was using when it crashed. well, I have no PPPoE running and my OOPSen look very similar. (see MsgId <[EMAIL PROTECTED]>). I am using tulip, dummy, Ben Grear's dot1q VLAN devices and some ISDN syncppp and ISDN rawip devices are configured (but not actively used), too. Rainer -- KeyID=759975BD fingerprint=887A 4BE3 6AB7 EE3C 4AE0 B0E1 0556 E25A 7599 75BD - 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/
Re: page reserved twice
Hello D., Wednesday, July 04, 2001, 8:19:27 AM, you wrote: DS> I'm curious if there is any significance to this, which occurs at each DS> reboot on an SMP system running noapic (sometimes Netscape manages to DS> produce a hard lockup on the system, sometimes a core dump indicates NS DS> had signal 7, bus error, in cases where it doesn't lock the system), DS> 2.4.6-pre1 with XFS patches: DS> kernel: BIOS-provided physical RAM map: DS> kernel: BIOS-e820: - 0009fc00 (usable) DS> kernel: BIOS-e820: 0009fc00 - 000a (reserved) DS> kernel: BIOS-e820: 000e - 0010 (reserved) DS> kernel: BIOS-e820: 0010 - 0ffe (usable) DS> kernel: BIOS-e820: 0ffe - 0fff8000 (ACPI data) DS> kernel: BIOS-e820: 0fff8000 - 1000 (ACPI NVS) DS> kernel: Scan SMP from c000 for 1024 bytes. DS> kernel: Scan SMP from c009fc00 for 1024 bytes. DS> kernel: Scan SMP from c00f for 65536 bytes. DS> kernel: found SMP MP-table at 000faf50 DS> kernel: hm, page 000fa000 reserved twice. DS> kernel: hm, page 000fb000 reserved twice. DS> kernel: hm, page 000f4000 reserved twice. DS> thanteros kernel: hm, page 000f5000 reserved twice. DS> thanteros kernel: On node 0 totalpages: 65504 DS> thanteros kernel: zone(0): 4096 pages. DS> kernel: zone(1): 61408 pages. DS> kernel: zone(2): 0 pages. DS> kernel: Intel MultiProcessor Specification v1.1 DS> kernel: Virtual Wire compatibility mode. DS> kernel: OEM ID: _AMI_Product ID: 840_CARMEL__ APIC at: 0xFEE0 DS> Very similar messages seem to occur on a different machine with RH's DS> 2.4.2 kernel, BX chipset, and IO-APIC enabled. The machine this is from DS> has had this message on earlier kernels as well, none of which had XFS DS> patches. What is the significance (or consequence) of pages reserved DS> twice? I think that the message above doesn't matter with your nescape crash, When linux kernel boot, it reserve all usable low memory,for example kernel: BIOS-e820: 0009fc00 - 000a (reserved) kernel: BIOS-e820: 000e - 0010 (reserved) then kernel call find_smp_config to get MP configuration table if your machine is SMP, and the function will reserve the MP-table at 0xfa000,0xfb000, 0xf4000, and because these regions were reserved by kernel, so kernel would print the message, but it doesn't affect you system. -- Best regards, michaelcmailto:[EMAIL PROTECTED] - 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/
Re: page reserved twice
Hello D., Wednesday, July 04, 2001, 8:19:27 AM, you wrote: Wednesday, July 04, 2001, 8:19:27 AM, you wrote: DS> I'm curious if there is any significance to this, which occurs at each DS> reboot on an SMP system running noapic (sometimes Netscape manages to DS> produce a hard lockup on the system, sometimes a core dump indicates NS DS> had signal 7, bus error, in cases where it doesn't lock the system), DS> 2.4.6-pre1 with XFS patches: DS> kernel: BIOS-provided physical RAM map: DS> kernel: BIOS-e820: - 0009fc00 (usable) DS> kernel: BIOS-e820: 0009fc00 - 000a (reserved) DS> kernel: BIOS-e820: 000e - 0010 (reserved) DS> kernel: BIOS-e820: 0010 - 0ffe (usable) DS> kernel: BIOS-e820: 0ffe - 0fff8000 (ACPI data) DS> kernel: BIOS-e820: 0fff8000 - 1000 (ACPI NVS) DS> kernel: Scan SMP from c000 for 1024 bytes. DS> kernel: Scan SMP from c009fc00 for 1024 bytes. DS> kernel: Scan SMP from c00f for 65536 bytes. DS> kernel: found SMP MP-table at 000faf50 DS> kernel: hm, page 000fa000 reserved twice. DS> kernel: hm, page 000fb000 reserved twice. DS> kernel: hm, page 000f4000 reserved twice. DS> thanteros kernel: hm, page 000f5000 reserved twice. DS> thanteros kernel: On node 0 totalpages: 65504 DS> thanteros kernel: zone(0): 4096 pages. DS> kernel: zone(1): 61408 pages. DS> kernel: zone(2): 0 pages. DS> kernel: Intel MultiProcessor Specification v1.1 DS> kernel: Virtual Wire compatibility mode. DS> kernel: OEM ID: _AMI_Product ID: 840_CARMEL__ APIC at: 0xFEE0 DS> Very similar messages seem to occur on a different machine with RH's DS> 2.4.2 kernel, BX chipset, and IO-APIC enabled. The machine this is from DS> has had this message on earlier kernels as well, none of which had XFS DS> patches. What is the significance (or consequence) of pages reserved DS> twice? I think that the message above doesn't matter with your nescape crash, When linux kernel boot, it reserve all usable low memory,for example kernel: BIOS-e820: 0009fc00 - 000a (reserved) kernel: BIOS-e820: 000e - 0010 (reserved) then kernel call find_smp_config to get MP configuration table if your machine is SMP, and the function will reserve the MP-table at 0xfa000,0xfb000, 0xf4000, and because these regions were reserved by kernel, so kernel would print the message, so it doesn't cause any problem on your machine. -- Best regards, michael chenmailto:[EMAIL PROTECTED] - 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/
[PATCH re-sent] one more starfire net driver fix for 2.4.7pre6+
Hi,
This patch reverses the MII hunk from the previous patch (included in
2.4.7-pre6), which was apparently breaking some cards. It also fixes an
incorrect comment.
Please apply.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
--- linux-2.4/drivers/net/starfire.c.orig Thu Jul 12 10:15:18 2001
+++ linux-2.4/drivers/net/starfire.cThu Jul 12 10:17:30 2001
@@ -87,8 +87,7 @@
LK1.3.3 (Ion Badulescu)
- Initialize the TxMode register properly
- - Set the MII registers _after_ resetting it
- - Don't dereference dev->priv after unregister_netdev() has freed it
+ - Don't dereference dev->priv after freeing it
TODO:
- implement tx_timeout() properly
@@ -987,12 +986,12 @@
struct netdev_private *np = dev->priv;
u16 reg0;
+ mdio_write(dev, np->phys[0], MII_ADVERTISE, np->advertising);
mdio_write(dev, np->phys[0], MII_BMCR, BMCR_RESET);
udelay(500);
while (mdio_read(dev, np->phys[0], MII_BMCR) & BMCR_RESET);
reg0 = mdio_read(dev, np->phys[0], MII_BMCR);
- mdio_write(dev, np->phys[0], MII_ADVERTISE, np->advertising);
if (np->autoneg) {
reg0 |= BMCR_ANENABLE | BMCR_ANRESTART;
@@ -1939,12 +1938,12 @@
pci_free_consistent(pdev, PAGE_SIZE,
np->rx_ring, np->rx_ring_dma);
- unregister_netdev(dev); /* Will also free np!! */
+ unregister_netdev(dev);
iounmap((char *)dev->base_addr);
pci_release_regions(pdev);
pci_set_drvdata(pdev, NULL);
- kfree(dev);
+ kfree(dev); /* Will also free np!! */
}
-
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/
Re: Oops in 2.4.7-pre9.
Niels Kristian Bech Jensen wrote:
>
> I get this oops while booting 2.4.7-pre9:
Kernel is trying to read /proc/pid entries for a kernel thread
which has called daemonize(). It has a null task_struct.mm.
I tested various other possible problems, such as making
/sbin/hotplug an elf executable and it looks OK, apart from
the /proc problem.
--- linux-2.4.7-pre9/fs/proc/base.c Fri Jul 20 15:39:12 2001
+++ linux-akpm/fs/proc/base.c Fri Jul 20 16:43:02 2001
@@ -670,7 +670,7 @@ static struct inode *proc_pid_make_inode
inode->u.proc_i.task = task;
inode->i_uid = 0;
inode->i_gid = 0;
- if (ino == PROC_PID_INO || task->mm->dumpable) {
+ if (ino == PROC_PID_INO || (task->mm && task->mm->dumpable)) {
inode->i_uid = task->euid;
inode->i_gid = task->egid;
}
-
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/
Re: Oops in 2.4.7-pre9.
Niels Kristian Bech Jensen writes:
> >>EIP; c01467e3<=
This should fix it:
--- fs/proc/base.c.~1~ Thu Jul 19 23:02:12 2001
+++ fs/proc/base.c Thu Jul 19 23:25:28 2001
@@ -670,7 +670,8 @@
inode->u.proc_i.task = task;
inode->i_uid = 0;
inode->i_gid = 0;
- if (ino == PROC_PID_INO || task->mm->dumpable) {
+ if (ino == PROC_PID_INO ||
+ (task->mm && task->mm->dumpable)) {
inode->i_uid = task->euid;
inode->i_gid = task->egid;
}
-
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/
[PATCH] PnP BIOS: io range length bugfix
Hi all, this patch fixes bug in pnpbios_rawdata_2_pci_dev() - miscalculated length of ioport range. This function uses word at offset 6 in I/O Port Descriptor, but according to ISA PnP specification ioport range length is a byte at offset 7 and byte 6 is base alignment. BTW will it usefull to implement PnP device naming function ? Best regards. -- Andrey Panin| Embedded systems software engineer [EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc diff -urN -X /usr/dontdiff /linux.vanilla/drivers/pnp/pnp_bios.c /linux/drivers/pnp/pnp_bios.c --- /linux.vanilla/drivers/pnp/pnp_bios.c Tue Jul 17 23:11:14 2001 +++ /linux/drivers/pnp/pnp_bios.c Sat Jul 21 00:08:38 2001 @@ -669,7 +669,7 @@ break; case 0x08: // io io= p[2] + p[3] *256; - len= p[6] + p[7] *256; + len = p[7]; i=0; while(pci_dev->resource[i].start && i PGP signature
Oops in 2.4.7-pre9.
I get this oops while booting 2.4.7-pre9: Jul 20 08:01:52 hafnium kernel: Unable to handle kernel NULL pointer dereference at virtual address 007c Jul 20 08:01:52 hafnium kernel: c01467e3 Jul 20 08:01:52 hafnium kernel: *pde = Jul 20 08:01:52 hafnium kernel: Oops: Jul 20 08:01:52 hafnium kernel: CPU:0 Jul 20 08:01:52 hafnium kernel: EIP:0010:[proc_pid_make_inode+131/176] Jul 20 08:01:52 hafnium kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jul 20 08:01:52 hafnium kernel: EFLAGS: 00010206 Jul 20 08:01:52 hafnium kernel: eax: ebx: c11ba000 ecx: c48c89c0 edx: c104b578 Jul 20 08:01:52 hafnium kernel: esi: c11ed000 edi: 000b ebp: c01e0ca0 esp: c493de68 Jul 20 08:01:52 hafnium kernel: ds: 0018 es: 0018 ss: 0018 Jul 20 08:01:52 hafnium kernel: Process pidof (pid: 177, stackpage=c493d000) Jul 20 08:01:52 hafnium kernel: Stack: c11ba000 000b c01bf0aa c0146a3a c11ed000 c11ba000 000b c11ba000 Jul 20 08:01:52 hafnium kernel:ffea fff4 c01406a8 c1157e08 00f0 c4b6c9a0 fff4 c48c87e0 Jul 20 08:01:52 hafnium kernel:c4b6c920 c01388cf c48c87e0 c4b6c9a0 c493df00 c4b6c920 c4b6c920 c4fee00c Jul 20 08:01:52 hafnium kernel: Call Trace: [proc_base_lookup+138/544] [d_alloc+24/368] [real_lookup+79/192] [path_walk+1409/2000] [destroy_inode+48/64] [open_namei+124/1360] [filp_open+52/96] Jul 20 08:01:52 hafnium kernel: Call Trace: [] [] [] [] [] [] [] Jul 20 08:01:52 hafnium kernel:[] [] [] Jul 20 08:01:52 hafnium kernel: Code: f6 40 7c 01 74 12 8b 83 24 01 00 00 89 41 30 8b 83 34 01 00 >>EIP; c01467e3<= Trace; c0146a3a Trace; c01406a8 Trace; c01388cf Trace; c0138fd1 Trace; c0141050 Trace; c013972c Trace; c012e334 Trace; c013861f Trace; c012e636 Trace; c0106cf3 Code; c01467e3 <_EIP>: Code; c01467e3<= 0: f6 40 7c 01 testb $0x1,0x7c(%eax) <= Code; c01467e7 4: 74 12 je 18 <_EIP+0x18> c01467fb Code; c01467e9 6: 8b 83 24 01 00 00 mov0x124(%ebx),%eax Code; c01467ef c: 89 41 30 mov%eax,0x30(%ecx) Code; c01467f2 f: 8b 83 34 01 00 00 mov0x134(%ebx),%eax -- Niels Kristian Bech Jensen -- [EMAIL PROTECTED] -- http://www.image.dk/~nkbj/ --->> Stop software piracy --- use free software! <<--- - 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/
[PATCH] 2.4.7-pre8 scc.c vector latch region allocation
> This patch fixes a failure in the scc.c driver to properly allocate the
I/O
> region for the interrupt vector latch, which is present on some ham radio
> SCC cards, such as the PA0HZP card.
>
> Rob Turk - PE1KOX
>
After receiving a few hints that uu-encoded messages are 'not done', here's
the same patch in text format. Sorry for any confusion.
Rob
--- linux.org/drivers/net/hamradio/scc.c Thu Jul 19 22:48:06 2001
+++ linux/drivers/net/hamradio/scc.c Thu Jul 19 20:55:58 2001
@@ -1775,8 +1775,8 @@
Ivec[hwcfg.irq].used = 1;
}
- if (hwcfg.vector_latch) {
-if (!request_region(Vector_Latch, 1, "scc vector latch"))
+ if (hwcfg.vector_latch && !Vector_Latch) {
+if (!request_region(hwcfg.vector_latch, 1, "scc vector latch"))
printk(KERN_WARNING "z8530drv: warning, cannot reserve vector latch
port 0x%lx\n, disabled.", hwcfg.vector_latch);
else
Vector_Latch = hwcfg.vector_latch;
-
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/
1GB system working with 64MB - Solved
Problem solved. This is one top output: 5:47pm up 21 min, 2 users, load average: 0.99, 0.70, 0.48 110 processes: 109 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 0.1% user, 2.4% system, 0.0% nice, 96.4% idle CPU1 states: 0.1% user, 5.4% system, 0.0% nice, 93.5% idle Mem: 906424K av, 904296K used,2128K free, 19808K shrd, 20956K buff Swap: 514040K av, 17176K used, 496864K free 710672K cached The system is using now 906MB rather than 1024, but at this time of the day I am quite happy comapred with the 64MB used before. Next step will be to go on 2.4.x Thanks Hello Folks, Environment: linux 2.2.16smp RedHat 7.0 I am setting up a system with 1GB RAM recongized by the BIOS during power-on procedure. This system having troubles, I set a top command and with surprise I got this status: 4:33pm up 4:42, 3 users, load average: 4.18, 2.01, 1.09 125 processes: 123 sleeping, 2 running, 0 zombie, 0 stopped CPU0 states: 9.1% user, 9.0% system, 8.0% nice, 80.1% idle CPU1 states: 20.0% user, 6.1% system, 20.1% nice, 72.0% idle Mem:63892K av, 62480K used,1412K free, 15076K shrd,5192K buff Swap: 514040K av, 260556K used, 253484K free 11804K cached My problem are the 63892K I remember there is a solution to turn around this problem forcing LILO to configure 1GB saying, I think but not sure: append='memory=1024' I searched in the lilo doc for memory parameter definition, but as being coverd by append parameter I found nothing. Question 1: Do you have an idea about the reason Linux is using 64MB ? Question 2: Is this append command correct to turn out this problem ? Question 3: Where can I found informations about append variables wich are related in fact with modules parameters ? How to find on source code which module will read the memory parameter ? Thanks in advance. Bye - 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/
2.4.7-pre9..
I'm getting ready to do a 2.4.7, but one of the fixes in 2.4.7 is a nasty SMP race that was found and made it clear that using an old trick of having a semaphore on the stack and doing "down()" on it to wait for some event (that would do the "up()") was a really bad idea. This kind of trick was used in the kernel vfork() implementation, and also in block device "wait for request completion". I've fixed both with a new and fairly simple "wait for completion" infrastructure, but I'd like especially SCSI device driver writers to check their own drivers as a result before I make the final 2.4.7. I've changed all generic code, so drivers are all expected to compile and work. However, some SCSI drivers use the semaphore trick in their own code, and I've not mucked with that. It's not worth worrying about too much, as the race is basically impossible to hit (famous last words), but I wanted a heads-up and people to give it a quick look. I also wanted to have people who actually have the hardware in question to verify that my untested (but on the face of it obvious) changes are indeed working. So please give it a quick spin, Linus - 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/
Warning: indirect lcall without `*'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.6/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c -o apm.o apm.c
{standard input}: Assembler messages:
{standard input}:188: Warning: indirect lcall without `*'
{standard input}:265: Warning: indirect lcall without `*'
make[1]: Leaving directory `/usr/src/linux-2.4.6/arch/i386/kernel'
make -C arch/i386/mm CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.6/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/linux-2.4.6/arch/i386/mm'
make[1]: Nothing to be done for `modules'.
make[1]: Leaving directory `/usr/src/linux-2.4.6/arch/i386/mm'
make -C arch/i386/lib CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.6/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/linux-2.4.6/arch/i386/lib'
make[1]: Nothing to be done for `modules'.
make[1]: Leaving directory `/usr/src/linux-2.4.6/arch/i386/lib'
[root@kiwiunix linux]#
--
WARNING:
This email was written on an OS using the viral 'GPL' as its license.
Please check with Bill Gates before continuing to read this email/posting.
-
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/
Re: bitops.h ifdef __KERNEL__ cleanup.
Followup to: <[EMAIL PROTECTED]> By author:David Woodhouse <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > It has been stated many times that kernel headers should not be used in > apps. Renaming or moving them should not be necessary - and people would > probably only start to use them again anyway. We'd see autoconf checks to > find whether it's linux/private.h or xunil/private.h :) > > In the absence of any expectation that userspace developers will ever obey > the simple and oft-repeated rule that you don't use kernel headers from > userspace, the #ifdef __KERNEL__ approach would seem to be the best on > offer. > Note that the rule is at least in part theoretical; even glibc include kernel headers or -derivatives. I think the idea with is that they are protected by #ifdef __KERNEL__ if they are kernel-only; however, if they work in user space then there is no #ifdef and autoconf can detect their presence. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
Re: MTD compiling error
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock': > /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared > (first use in this function) > /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier > is reported only once > /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: for each function it > appears in.) > make[3]: *** [cfi_probe.o] Error 1 > make[3]: Leaving directory `/usr/src/linux-2.4.6/drivers/mtd/chips' > make[2]: *** [_modsubdir_chips] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4.6/drivers/mtd' > make[1]: *** [_modsubdir_mtd] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.6/drivers' > make: *** [_mod_drivers] Error 2 > [root@kiwiunix linux]# > > After adding #include in the CFI.h header file, the result was > that there is a undeclared identifier. Since I don't know C (Only java, BBC > Basic, and COBOL), I don't know how to correct the problem. include I believe. It is fixed in MTD's CVS - 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/
[PATCH] nfsroot uses bogus mountd version for NFSv2
nfsroot uses bogus protocol version when it asks portmapper on
server for mountd port. Fix is obvious:
--- linux/fs/nfs/nfsroot.cFri Feb 16 18:56:03 2001
+++ linux/fs/nfs/nfsroot.c.new Thu Jul 19 23:55:09 2001
@@ -418,7 +418,7 @@
"as nfsd port\n", port);
}
- if ((port = root_nfs_getport(NFS_MNT_PROGRAM, nfsd_ver, proto)) < 0) {
+ if ((port = root_nfs_getport(NFS_MNT_PROGRAM, mountd_ver, proto)) < 0) {
printk(KERN_ERR "Root-NFS: Unable to get mountd port "
"number from server, using default\n");
port = mountd_port;
Notice that for NFSv3 both nfsd and mountd are using version 3, so it both
nfsd_ver == mountd_ver. However, for NFSv2 we end up asking for mountd
version 2, which doesn't exist - mountd version for NFSv2 was 1.
Looks like this typo got into the tree in 2.3.99-4-pre3 when NFSv3 had
been merged into the tree - until then we had (correctly) asked for
version 1. Corresponding code in 2.2 is using mountd_ver, so it's also
OK.
-
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/
Re: MTD compiling error
gcc -D__KERNEL__ -I/usr/src/linux-2.4.6/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c -o cfi_probe.o cfi_probe.c In file included from cfi_probe.c:17: /usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock': /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared (first use in this function) /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier is reported only once /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: for each function it appears in.) make[3]: *** [cfi_probe.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.6/drivers/mtd/chips' make[2]: *** [_modsubdir_chips] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.6/drivers/mtd' make[1]: *** [_modsubdir_mtd] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.6/drivers' make: *** [_mod_drivers] Error 2 [root@kiwiunix linux]# After adding #include in the CFI.h header file, the result was that there is a undeclared identifier. Since I don't know C (Only java, BBC Basic, and COBOL), I don't know how to correct the problem. Matthew Gardiner -- WARNING: This email was written on an OS using the viral 'GPL' as its license. Please check with Bill Gates before continuing to read this email/posting. - 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/
Loop broken again (2.4.6-ac4)
Jens, Remember several weeks ago when I mentioned a problem w/ ridicyulous mod-use counts w/ loop.o??? Well, it's back again 2.4.5-ac19 (IIRC) worked fine. Basically, the result of attempting sudo losetup -d /dev/loop0 is the following ioctl LOOP_CLR_FD Device or resource busy strace shows EBUSY lsmod shows a use count of 563. - 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/
Re: Resend inlined text: [PATCH] Minor cleanup and export three functions
At 03:58 20/07/2001, Anton Altaparmakov wrote: >This is clearly not my day for sending emails... > >Sorry. The attachment was fine on last email but a little misunderstanding >between elm and myself resulted in the invention of two non-existent email >addresses and put them in the To: field. )-: Just remove them before >replying... They are quite obvious: [EMAIL PROTECTED], [EMAIL PROTECTED] > >Just trying to preempt the flames I am bound to get for that mess up... At >least I know how to do it properly next time. (-: And I just realized I can't spell Torvalds properly either. Linus, sincerely I apologize. I am going away to hide my head in the sand now... /-: Best regards, Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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/
Re: Resend inlined text: [PATCH] Minor cleanup and export three functions
This is clearly not my day for sending emails... Sorry. The attachment was fine on last email but a little misunderstanding between elm and myself resulted in the invention of two non-existent email addresses and put them in the To: field. )-: Just remove them before replying... They are quite obvious: [EMAIL PROTECTED], [EMAIL PROTECTED] Just trying to preempt the flames I am bound to get for that mess up... At least I know how to do it properly next time. (-: Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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/
[BUG] "unregister_netdevice: waiting for eth0 to become free. Usage count = 2"
>Groan< The "unregister_netdevice" bug is back. I haven't been able to do extensive testing, but I have just encountered the message unregister_netdevice: waiting for eth0 to become free. Usage count = 2 again. Once it starts, it repeats ad infinitum, once per second. The message starts spewing when I do a "cardctl eject" on a Xircom CEM56 modem/ethernet card (driven by xirc2ps_cs.o, serial.o) which was previously configured using DHCP with IPX enabled. The cardctl eject never completes and the OS will not shut down completely; it hangs at the point where it tries to de-configure network interfaces. Disabling IPX cured the problem for me the next time I tried. I am running 2.4.6-ac2, but the bug could have been reintroduced a while back. I haven't been using Ethernet for a couple of months. Well, I'm no expert on the networking code, so I'll just suggest some things that look odd to me. I'm looking in net/ipx/af_ipx.c, tracing through ipxitf_create(). This function exits with dev->refcnt incremented ... unless something goes wrong, in which case the function exits through via a goto to "out_dev" which decrements the refcnt again. Likewise, ipxitf_auto_create() increments the dev refcnt (by doing a dev_hold(dev)) if all goes well. However when I look at ipxitf_delete(), which I presume ought to undo what the *_create() functions do, I see nothing that decrements the refcnt. If this is where the bug lies then I would suggest that the functions be documented to say that "this function exits with the refcnt incremented if blah blah blah", etc. As an aside, I notice that __dev_get_by_name() is called from ipxitf_delete(). A comment preceding __dev_get_by_name() in net/core/dev.c says that this function should be called "under RTNL semaphore or @dev_base_lock", but it is actually called under the ipx_interfaces_lock. Is this okay? __dev_get_by_name() is also called from within ipxitf_ioctl(), seemingly under no locks at all. Also okay? Thomas Hood - 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/
Resend inlined text: [PATCH] Minor cleanup and export three functions
Sorry for confusion. Here goes again, sent with elm, and tested for being
clear text inline and that white space is not mangled.
-
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the offset/index parameter "const" in those
functions.
- More importantly, the patch exports the following three functions:
from mm/filemap.c (adding to include/linux/pagemap.h):
__find_page_nolock()
__add_to_page_cache()
from fs/buffer.c (adding to include/linux/fs.h):
create_empty_buffers()
The static keyword is removed, they are added to the indicated header
files as extern or extern inline as appropriate, and they are also added
to kernel/ksyms.c.
These three functions are used by the new NTFS driver which is under
development and in specific in the inode metadata in page cache part. I
have looked at alternatives but they lead to much nastier complications
within the ntfs code. (E.g. due to forcing me to drop the pagecache_lock
if I were to use add_to_page_cache() function instead of
__add_to_page_cache() which would in turn lead to potential race
condition, and anyway dropping the lock to only reacquire it straight
after returning after the function seems very inefficient.)
Any objections to the patch? If not, please apply. Thanks!
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
--- Patch follows this line ---
diff -urN linux-2.4.7-pre8-vanilla/fs/buffer.c
linux-2.4.7-pre8-tng-mrproper/fs/buffer.c
--- linux-2.4.7-pre8-vanilla/fs/buffer.cThu Jul 19 18:53:17 2001
+++ linux-2.4.7-pre8-tng-mrproper/fs/buffer.c Thu Jul 19 20:45:00 2001
@@ -1434,7 +1434,8 @@
return 1;
}
-static void create_empty_buffers(struct page *page, kdev_t dev, unsigned long
blocksize)
+void create_empty_buffers(struct page *page, kdev_t dev,
+ unsigned long blocksize)
{
struct buffer_head *bh, *head, *tail;
diff -urN linux-2.4.7-pre8-vanilla/include/linux/fs.h
linux-2.4.7-pre8-tng-mrproper/include/linux/fs.h
--- linux-2.4.7-pre8-vanilla/include/linux/fs.h Thu Jul 19 18:53:19 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/fs.hThu Jul 19 23:02:10 2001
@@ -1320,6 +1320,8 @@
typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int);
+extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
+
/* Generic buffer handling for block filesystems.. */
extern int block_flushpage(struct page *, unsigned long);
extern int block_symlink(struct inode *, const char *, int);
diff -urN linux-2.4.7-pre8-vanilla/include/linux/pagemap.h
linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h
--- linux-2.4.7-pre8-vanilla/include/linux/pagemap.hTue Jul 3 23:42:57 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h Thu Jul 19 21:08:33
+2001
@@ -60,7 +60,8 @@
* For the time being it will work for struct address_space too (most of
* them sitting inside the inodes). We might want to change it later.
*/
-extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
+extern inline unsigned long _page_hashfn(struct address_space *mapping,
+ const unsigned long index)
{
#define i (((unsigned long) mapping)/(sizeof(struct inode) & ~ (sizeof(struct inode)
- 1)))
#define s(x) ((x)+((x)>>PAGE_HASH_BITS))
@@ -75,6 +76,8 @@
unsigned long offset, struct page **hash);
extern struct page * __find_lock_page (struct address_space * mapping,
unsigned long index, struct page **hash);
+extern inline struct page *__find_page_nolock(struct address_space *mapping,
+ const unsigned long offset, struct page *page);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
__find_lock_page(mapping, index, page_hash(mapping, index))
@@ -86,8 +89,13 @@
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
-extern void add_to_page_cache(struct page * page, struct address_space *mapping,
unsigned long index);
-extern void add_to_page_cache_locked(struct page * page, struct address_space
*mapping, unsigned long index);
+extern inline void __add_to_page_cache(struct page *page,
+ struct address_space *mapping, const unsigned long offset,
+ struct page **hash);
+extern void add_to_page_cache(struct page *page, struct address_space *mapping,
+ const unsigned long index);
+extern void add_to_page_cache_locked(struct page *page,
+ struct address_space *mapping, const unsigned long index);
extern void ___wait_on_page(struct page *);
Re: [PATCH] Minor cleanup and export three functions
At 3:03 AM +0100 2001-07-20, Anton Altaparmakov wrote: >I do appologize. I didn't realize pine would do this. In pine I can just >read the attachment as text and in Eudora it just appears as inlined >text without any indication of it being a separate attachment, so I just >assumed that it was sent clear text. Obviously not. Eudora does leave you one little clue: At 2:19 AM +0100 2001-07-20, Anton Altaparmakov wrote: >MIME-Version: 1.0 >Content-Type: MULTIPART/MIXED; >BOUNDARY="-559023410-1804928587-995591940=:20239" -- /Jonathan Lundell. - 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/
Re: [PATCH] Minor cleanup and export three functions
On Fri, 20 Jul 2001 03:03:58 +0100 (BST), Anton Altaparmakov <[EMAIL PROTECTED]> wrote: > I will repost as soon as I manage to convince pine of it's wrong ways... You can't, so don't bother. Just inline it, ctrl-r should do the trick. However be careful, newer pine's like to strip trailing spaces even from inlined files -- I've fixed mine but most distributions have the broken one. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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/
Re: [PATCH] Minor cleanup and export three functions
On Thu, 19 Jul 2001, Pete Zaitcev wrote: > > This message is in MIME format. The first part should be readable text, > > while the remaining parts are likely unreadable without MIME-aware tools. > > Quite so. Linus told you many times not to send patches > in MIME and I happen to agree. > > > Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-2.4.7-pre8-aia1" > > Content-Transfer-Encoding: BASE64 > > Content-ID: <[EMAIL PROTECTED]> > > Content-Description: > > > > ZGlmZiAtdXJOIGxpbnV4LTIuNC43LXByZTgtdmFuaWxsYS9mcy9idWZmZXIu > > YyBsaW51eC0yLjQuNy1wcmU4LXRuZy1tcnByb3Blci9mcy9idWZmZXIuYw0K > >[ lots of crap skipped ] > I do appologize. I didn't realize pine would do this. In pine I can just read the attachment as text and in Eudora it just appears as inlined text without any indication of it being a separate attachment, so I just assumed that it was sent clear text. Obviously not. I will repost as soon as I manage to convince pine of it's wrong ways... Best regards, Anton -- Anton Altaparmakov (replace at with @) Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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/
Re: 2.4.7pre8aa1
[EMAIL PROTECTED] said: > works fine thanks! Of course I agree with rmk it would be better not > to disable -fno-common but this is ok for now ;) Yeah, it's temporary. rmk's idea was to use the link script to toss errno.o out of the final binary. > (after all we would > catch any potential important name collision during the compiles of > the other targets) Agreed. -fno-common is definitely good. The only conflict is errno, but when Arjan first started playing with -fno-common, he found a couple of UML bugs. Jeff - 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/
Re: 2.4.7pre8aa1
On Thu, Jul 19, 2001 at 06:45:38PM -0400, Jeff Dike wrote: > > Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2 > > Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2 > > Moved part of it in the tux directory so it can compile > > without tux (in reality I got errno compilation error > > but it's low prio and I'll sort it out later, Jeff Dike any > > hint is welcome ;). > > This is the patch I sent to Alan a while back which works around the problem. > > rmk suggested a better way which I'll add at some point. > > Jeff > > > diff -Naur -X exclude-files ac_cur/arch/um/Makefile ac/arch/um/Makefile > --- ac_cur/arch/um/Makefile Mon Jul 9 13:05:03 2001 > +++ ac/arch/um/Makefile Mon Jul 9 13:26:21 2001 > @@ -20,6 +20,8 @@ > LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup > endif > > +CFLAGS := $(subst -fno-common,,$(CFLAGS)) > + > SUBDIRS += $(ARCH_DIR)/fs $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \ > $(ARCH_DIR)/sys-$(SUBARCH) works fine thanks! Of course I agree with rmk it would be better not to disable -fno-common but this is ok for now ;) (after all we would catch any potential important name collision during the compiles of the other targets) Andrea - 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/
Re: [PATCH] Minor cleanup and export three functions
> This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. Quite so. Linus told you many times not to send patches in MIME and I happen to agree. > Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-2.4.7-pre8-aia1" > Content-Transfer-Encoding: BASE64 > Content-ID: <[EMAIL PROTECTED]> > Content-Description: > > ZGlmZiAtdXJOIGxpbnV4LTIuNC43LXByZTgtdmFuaWxsYS9mcy9idWZmZXIu > YyBsaW51eC0yLjQuNy1wcmU4LXRuZy1tcnByb3Blci9mcy9idWZmZXIuYw0K >[ lots of crap skipped ] - 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/
[PATCH] Minor cleanup and export three functions
Linus,
Please consider attached patch. It does three things:
- Adds docbook style comments to a very few functions relating to the page
cache (mm/filemap.c) and does very minor clean up on those to keep within
80 character wide lines (only look affected).
- Minor cleanup making the offset/index parameter "const" in those
functions.
- More importantly, the patch exports the following three functions:
from mm/filemap.c (adding to include/linux/pagemap.h):
__find_page_nolock()
__add_to_page_cache()
from fs/buffer.c (adding to include/linux/fs.h):
create_empty_buffers()
The static keyword is removed, they are added to the indicated header
files as extern or extern inline as appropriate, and they are also added
to kernel/ksyms.c.
These three functions are used by the new NTFS driver which is under
development and in specific in the inode metadata in page cache part. I
have looked at alternatives but they lead to much nastier complications
within the ntfs code. (E.g. due to forcing me to drop the pagecache_lock
if I were to use add_to_page_cache() function instead of
__add_to_page_cache() which would in turn lead to potential race
condition, and anyway dropping the lock to only reacquire it straight
after returning after the function seems very inefficient.)
Any objections to the patch? If not, please apply. Thanks!
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
diff -urN linux-2.4.7-pre8-vanilla/fs/buffer.c
linux-2.4.7-pre8-tng-mrproper/fs/buffer.c
--- linux-2.4.7-pre8-vanilla/fs/buffer.cThu Jul 19 18:53:17 2001
+++ linux-2.4.7-pre8-tng-mrproper/fs/buffer.c Thu Jul 19 20:45:00 2001
@@ -1434,7 +1434,8 @@
return 1;
}
-static void create_empty_buffers(struct page *page, kdev_t dev, unsigned long
blocksize)
+void create_empty_buffers(struct page *page, kdev_t dev,
+ unsigned long blocksize)
{
struct buffer_head *bh, *head, *tail;
diff -urN linux-2.4.7-pre8-vanilla/include/linux/fs.h
linux-2.4.7-pre8-tng-mrproper/include/linux/fs.h
--- linux-2.4.7-pre8-vanilla/include/linux/fs.h Thu Jul 19 18:53:19 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/fs.hThu Jul 19 23:02:10 2001
@@ -1320,6 +1320,8 @@
typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int);
+extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
+
/* Generic buffer handling for block filesystems.. */
extern int block_flushpage(struct page *, unsigned long);
extern int block_symlink(struct inode *, const char *, int);
diff -urN linux-2.4.7-pre8-vanilla/include/linux/pagemap.h
linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h
--- linux-2.4.7-pre8-vanilla/include/linux/pagemap.hTue Jul 3 23:42:57 2001
+++ linux-2.4.7-pre8-tng-mrproper/include/linux/pagemap.h Thu Jul 19 21:08:33
+2001
@@ -60,7 +60,8 @@
* For the time being it will work for struct address_space too (most of
* them sitting inside the inodes). We might want to change it later.
*/
-extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
+extern inline unsigned long _page_hashfn(struct address_space *mapping,
+ const unsigned long index)
{
#define i (((unsigned long) mapping)/(sizeof(struct inode) & ~ (sizeof(struct inode)
- 1)))
#define s(x) ((x)+((x)>>PAGE_HASH_BITS))
@@ -75,6 +76,8 @@
unsigned long offset, struct page **hash);
extern struct page * __find_lock_page (struct address_space * mapping,
unsigned long index, struct page **hash);
+extern inline struct page *__find_page_nolock(struct address_space *mapping,
+ const unsigned long offset, struct page *page);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
__find_lock_page(mapping, index, page_hash(mapping, index))
@@ -86,8 +89,13 @@
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
-extern void add_to_page_cache(struct page * page, struct address_space *mapping,
unsigned long index);
-extern void add_to_page_cache_locked(struct page * page, struct address_space
*mapping, unsigned long index);
+extern inline void __add_to_page_cache(struct page *page,
+ struct address_space *mapping, const unsigned long offset,
+ struct page **hash);
+extern void add_to_page_cache(struct page *page, struct address_space *mapping,
+ const unsigned long index);
+extern void add_to_page_cache_locked(struct page *page,
+ struct address_space *mapping, const unsigned long index);
extern void ___wait_on_page(struct page *);
diff -urN linux-2.4.7-pre8-vanilla/kernel/ksyms.c
linux-2.4.7-pre8-tng-mrproper/kernel/ksyms.c
--- linux-2.4.7
Re: Stability of ReiserFS onj Kernel 2.4.x (sp. 2.4.[56]{-ac*}
On Sunday 15 July 2001 20:22, Albert D. Cahalan wrote: > An extra 4 bits buys us 6 years maybe. Nice, except that we > already have people complaining. Maybe somebody remembers when > the complaining started. I blame Charles Babbage, myself... As for the scalable block numbers, assuming moore's law holds at 18 months/doubling without hitting subatomic quantum weirdness limits, the jump from 32 to 64 bits gives us another 48 years. 48 years ago was 1953. Univac (powered by vacuum tubes) hit the market in 1951. Project whirlwind would do prototype work applying transistors to computers in 1954. Just a sense of perspective. Scalable block numbers sound cool if they save metadata space, but not as a source of extra scalability. And they sound like a can of worms in terms of complexity. Feel free to bring up the Y2K problem as a counter-example as to why "rewriting it when it becomes a problem" is a bad idea. But the problem there was closed (and lost) source code, wasn't it? Rob - 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/
Re: modules/ksyms/filenames
On Thu, 19 Jul 2001 15:54:00 -0600, "Peter J. Braam" <[EMAIL PROTECTED]> wrote: >I'm trying to export a symbol (journal_begin/end) from >fs/reiserfs/journal.c. To export the symbols I added to the Makefile: >export-objs := journal.o > >There is also a file fs/jbd/journal.c which exports symbols. It is a "feature" of the module symbol versioning that all objects which export symbols must have globally unique basenames. Stupid, I know, and it will disappear in 2.5. In the meantime, create fs/reiserfs/reiserfs_ksyms.c and export the symbols in there. See kernel/ksyms.c for an example. - 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/
Re: Oops (NULL pointer dereference) with 2.4.5+xfs-1.0.1
hi, On Jul 19, 5:04pm, Poul Petersen wrote: > Subject: Oops (NULL pointer dereference) with 2.4.5+xfs-1.0.1 > I'm running RedHat 7.1 with the manually patched 2.4.5 kernel and > xfs-1.0.1 on a dual PII (400) with 1 Gig of RAM. The XFS filesystems are > located on a SAN RAID device accessed through a qlogic 2100 Fibre Channel > card (using the qla2x00 module provided by Qlogic, ver 4.25). This system > acts as a "gateway" by mounting the disks from the SAN and then exporting > them to an array of hosts (Solaris, IRIX, Linux, AIX, etc) via NFS. The > system has been stable through heavy read/write testing that moved > approximately 5TB of data. Then we got an oops and the system locked up - we > don't have the kernel debugger loaded and syslog didn't catch it, so I don't > have a record of that oops. I'm not sure I can help on this initial problem, too little information for a post mortum - but this one... > We hard rebooted the system and within 10 > minutes while authenticating mount requests we got the same oops - > > rpc.mountd: authenticated mount request from 10.68.9.3:1022 for > /san/devbuild (/san/devbuild) > kernel: Unable to handle kernel NULL pointer dereference at virtual address > 009c > kernel: printing eip: > kernel: c01f1e98 > kernel: *pde = > kernel: Oops: 0002 > kernel: CPU:0 > kernel: EIP:0010:[] > kernel: EFLAGS: 00010002 > kernel: eax: 0074 ebx: 0074 ecx: 0004 edx: ffe8 > kernel: esi: ffe8 edi: c01c88a9 ebp: f3f9a54c esp: f4ae5aac > kernel: ds: 0018 es: 0018 ss: 0018 > kernel: Process nfsd (pid: 682, stackpage=f4ae5000) > kernel: Stack: 0004 ffe8 c01c88a9 c01c8d94 0074 0288 > ffe8 f3f9a560 > kernel:c033bf20 c01c8de3 ffe8 0004 c01c88a9 c01c88a9 > ffe8 0004 > kernel: 10130323 f7c5d800 f3d14e40 0004 > c01ddb16 f7c5d800 > kernel: Call Trace: [] [] [] [] > [] [] [] > kernel:[] [] [] [] > [] [] [] [] > kernel:[] [] [] [] > [] [] [] [] > kernel:[] [] [] [] > [] [] [] > kernel: > kernel: Code: f0 fe 4b 28 0f 88 1a f3 0c 00 8b 0b 85 c9 74 20 8d 7b 28 8d > > This time the system did not crash, but the nfsd (pid 682) died and > nfs was altogether broken. Since we couldn't get nfs to shut down, we > rebooted again. At this point we reviewed changes to the system since the > 5TB testing period and the only thing changed was we enabled quotas on one > of the XFS partitions (Some of the testing was with quotas on, but not all). > So, we removed "usrquota,grpquota" from /etc/fstab for that partition and > the system has been fine since (31 hours now). I've dug through a vast > amount of mailing list archives for both XFS and knfsd, but all of the > similar problems were resolved with patches which seem to already be > included in 2.4.5 and xfs-1.0.1 (I checked the code). We have since brought > up another system with the same software configuration (hardware is a single > PII-333 with 196 MB RAM). On this machine we enabled quotas and started > hammering on it. It has been running for 24 hours and has moved almost 3/4 > of a TB without any problems, so I'm not convinced that quotas was the > problem. I'm not even really certain that this is an XFS problem, except we > haven't seen this problem on other non-XFS files servers that we have and > this problem seemed at least similar to a previous XFS problem: > http://search.luky.org/linux-kernel.2001/msg12490.html > > Any insight would be greatly appreciated. > There is one known problem where a mount with quota enabled has caused a panic on a local QA system, also with a NULL pointer dereference which may be causing this problem. I'm having the devil's own job trying to reproduce it - but will CC you when I do have a fix for it - may solve your problem. If you survived the mount (with quota enabled), then this is not the problem and there are no other known problems with XFS quota, so we'd need to extract some more information to diagnose further. cheers. -- Nathan - 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/
Re: Busy inodes after umount
On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote: > I know there was a fix for a "Busy inodes after unmount" problem in > 2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list > from Neil Brown: Thanks. I'll try that and see if that solves the problem (also the XFS UUID problem). -- Ragnar Kjorstad Big Storage - 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/
MTD compiling error
In file included from cfi_probe.c:17: /usr/src/linux-2.4.6/include/linux/mtd/cfi.h: In function `cfi_spin_unlock': /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared (first use in this function) /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: (Each undeclared identifier is reported only once /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: for each function it appears in.) make[3]: *** [cfi_probe.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.6/drivers/mtd/chips' make[2]: *** [_modsubdir_chips] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.6/drivers/mtd' make[1]: *** [_modsubdir_mtd] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.6/drivers' make: *** [_mod_drivers] Error 2 [root@kiwiunix linux]# mtd is buggered. Found out when compiling the modules. Matthew Gardiner -- WARNING: This email was written on an OS using the viral 'GPL' as its license. Please check with Bill Gates before continuing to read this email/posting. - 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/
Re: Busy inodes after umount
I know there was a fix for a "Busy inodes after unmount" problem in
2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list
from Neil Brown:
-Included message---
Previously anonymous dentries were hashed (though with no name, the
hash was pretty meaningless). This meant that they would hang around
after the last reference was dropped. This was actually fairly
pointless as they would never get referenced again, and caused a real
problem as umount wouldn't discard them and so you got the message
printk("VFS: Busy inodes after unmount. "
"Self-destruct in 5 seconds. Have a nice day...\n");
In 2.4.6-pre3 I stopped hashing those dentries so now when the last
reference is dropped, the dentry is freed. So now there will never be
more anonymous dentries than there are active nfsd threads.
---end included message---
Tad
>
> I reported this a couple of months back. It's reassuring to know that it's a
> consistent problem.
>
> On Fri, 20 Jul 2001, [iso-8859-1] Ragnar Kjørstad wrote:
>
> > On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
> > > I found the same thing happening. Tracked it down in our case to using fdisk to
>re-read disk size before mounting. Replaced it with "blockdev --readpt" and the
>problem seems to have gone away. YMMV.
> >
> > I've now been able to reproduce:
> >
> > * make a filesystem
> > * mount it
> > * export it (nfs)
> > * mount on remote machine
> > * lock file (fcntl)
> > * unexport
> > * unmount
> >
> > Then you get the VFS message about self-destruct. Tested with both ext2
> > and xfs.
> >
> > The lock is still present in /proc/locks after the umount.
> >
> > With ext2 I can remount the filesystem successfully, but with XFS I get
> > the message about duplicate UUIDs and the mount failes. I believe this is a totally
> > different problem from the one you were experiencing. (and blockdev doesn't help
>for me)
> >
> > I suppose this is a generic kernel bug?
> >
> >
> >
>
-
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/
Oops (NULL pointer dereference) with 2.4.5+xfs-1.0.1
I'm running RedHat 7.1 with the manually patched 2.4.5 kernel and xfs-1.0.1 on a dual PII (400) with 1 Gig of RAM. The XFS filesystems are located on a SAN RAID device accessed through a qlogic 2100 Fibre Channel card (using the qla2x00 module provided by Qlogic, ver 4.25). This system acts as a "gateway" by mounting the disks from the SAN and then exporting them to an array of hosts (Solaris, IRIX, Linux, AIX, etc) via NFS. The system has been stable through heavy read/write testing that moved approximately 5TB of data. Then we got an oops and the system locked up - we don't have the kernel debugger loaded and syslog didn't catch it, so I don't have a record of that oops. We hard rebooted the system and within 10 minutes while authenticating mount requests we got the same oops - rpc.mountd: authenticated mount request from 10.68.9.3:1022 for /san/devbuild (/san/devbuild) kernel: Unable to handle kernel NULL pointer dereference at virtual address 009c kernel: printing eip: kernel: c01f1e98 kernel: *pde = kernel: Oops: 0002 kernel: CPU:0 kernel: EIP:0010:[] kernel: EFLAGS: 00010002 kernel: eax: 0074 ebx: 0074 ecx: 0004 edx: ffe8 kernel: esi: ffe8 edi: c01c88a9 ebp: f3f9a54c esp: f4ae5aac kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process nfsd (pid: 682, stackpage=f4ae5000) kernel: Stack: 0004 ffe8 c01c88a9 c01c8d94 0074 0288 ffe8 f3f9a560 kernel:c033bf20 c01c8de3 ffe8 0004 c01c88a9 c01c88a9 ffe8 0004 kernel: 10130323 f7c5d800 f3d14e40 0004 c01ddb16 f7c5d800 kernel: Call Trace: [] [] [] [] [] [] [] kernel:[] [] [] [] [] [] [] [] kernel:[] [] [] [] [] [] [] [] kernel:[] [] [] [] [] [] [] kernel: kernel: Code: f0 fe 4b 28 0f 88 1a f3 0c 00 8b 0b 85 c9 74 20 8d 7b 28 8d This time the system did not crash, but the nfsd (pid 682) died and nfs was altogether broken. Since we couldn't get nfs to shut down, we rebooted again. At this point we reviewed changes to the system since the 5TB testing period and the only thing changed was we enabled quotas on one of the XFS partitions (Some of the testing was with quotas on, but not all). So, we removed "usrquota,grpquota" from /etc/fstab for that partition and the system has been fine since (31 hours now). I've dug through a vast amount of mailing list archives for both XFS and knfsd, but all of the similar problems were resolved with patches which seem to already be included in 2.4.5 and xfs-1.0.1 (I checked the code). We have since brought up another system with the same software configuration (hardware is a single PII-333 with 196 MB RAM). On this machine we enabled quotas and started hammering on it. It has been running for 24 hours and has moved almost 3/4 of a TB without any problems, so I'm not convinced that quotas was the problem. I'm not even really certain that this is an XFS problem, except we haven't seen this problem on other non-XFS files servers that we have and this problem seemed at least similar to a previous XFS problem: http://search.luky.org/linux-kernel.2001/msg12490.html Any insight would be greatly appreciated. Thanks, -poul - 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/
Re: Busy inodes after umount
I reported this a couple of months back. It's reassuring to know that it's a consistent problem. On Fri, 20 Jul 2001, [iso-8859-1] Ragnar Kjørstad wrote: > On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote: > > I found the same thing happening. Tracked it down in our case to using fdisk to >re-read disk size before mounting. Replaced it with "blockdev --readpt" and the >problem seems to have gone away. YMMV. > > I've now been able to reproduce: > > * make a filesystem > * mount it > * export it (nfs) > * mount on remote machine > * lock file (fcntl) > * unexport > * unmount > > Then you get the VFS message about self-destruct. Tested with both ext2 > and xfs. > > The lock is still present in /proc/locks after the umount. > > With ext2 I can remount the filesystem successfully, but with XFS I get > the message about duplicate UUIDs and the mount failes. I believe this is a totally > different problem from the one you were experiencing. (and blockdev doesn't help for >me) > > I suppose this is a generic kernel bug? > > > - 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/
Re: Busy inodes after umount
On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote: > I found the same thing happening. Tracked it down in our case to using fdisk to >re-read disk size before mounting. Replaced it with "blockdev --readpt" and the >problem seems to have gone away. YMMV. I've now been able to reproduce: * make a filesystem * mount it * export it (nfs) * mount on remote machine * lock file (fcntl) * unexport * unmount Then you get the VFS message about self-destruct. Tested with both ext2 and xfs. The lock is still present in /proc/locks after the umount. With ext2 I can remount the filesystem successfully, but with XFS I get the message about duplicate UUIDs and the mount failes. I believe this is a totally different problem from the one you were experiencing. (and blockdev doesn't help for me) I suppose this is a generic kernel bug? -- Ragnar Kjorstad Big Storage > [root@ha2 /root]# mkfs -t xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256agcount=51, agsize=262144 > blks > data = bsize=4096 blocks=13305828, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1624 > realtime =none extsz=65536 blocks=0, rtextents=0 > [root@ha2 /root]# mount -t xfs /dev/sdb1 /mnt/raid/ > [root@ha2 /root]# umount /mnt/raid/ > [root@ha2 /root]# mount -t xfs /dev/sdb1 /mnt/raid/ > mount: wrong fs type, bad option, bad superblock on /dev/sdb1, >or too many mounted file systems > > > >From /var/log/messages: > Jul 19 12:27:15 ha2 kernel: Start mounting filesystem: sd(8,17) > Jul 19 12:27:16 ha2 kernel: Ending clean XFS mount for filesystem: sd(8,17) > Jul 19 12:27:19 ha2 kernel: XFS unmount got error 16 > Jul 19 12:27:19 ha2 kernel: linvfs_put_super: vfsp/0xc2ff71e0 left dangling! > Jul 19 12:27:19 ha2 kernel: VFS: Busy inodes after unmount. Self-destruct in 5 >seconds. Have a nice day... > Jul 19 12:27:21 ha2 kernel: XFS: Filesystem has duplicate UUID - can't mount > > > This happens on a shared storage cluster with two nodes. The same thing > happens on both nodes. (I'm only using the device from one device at the > time) > > linux-2.4.5 with XFS patch from 06112001. > > After a reboot it works again, and I have not been able to reproduce > yet. It first happened when I was testing NFS locks, so it could be > related to that. > > > > -- > Ragnar Kjorstad > Big Storage - 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/
Re: 2.4.7pre8aa1
> Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2 > Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2 > Moved part of it in the tux directory so it can compile > without tux (in reality I got errno compilation error > but it's low prio and I'll sort it out later, Jeff Dike any > hint is welcome ;). This is the patch I sent to Alan a while back which works around the problem. rmk suggested a better way which I'll add at some point. Jeff diff -Naur -X exclude-files ac_cur/arch/um/Makefile ac/arch/um/Makefile --- ac_cur/arch/um/Makefile Mon Jul 9 13:05:03 2001 +++ ac/arch/um/Makefile Mon Jul 9 13:26:21 2001 @@ -20,6 +20,8 @@ LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup endif +CFLAGS := $(subst -fno-common,,$(CFLAGS)) + SUBDIRS += $(ARCH_DIR)/fs $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \ $(ARCH_DIR)/sys-$(SUBARCH) - 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/
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem.(smp, iptables?))
Hey, I'm having trouble applying your first patch to kernel 2.4.6. I have a list of 18 failed hunks. The command I used is: cd /usr/src/linux && patch -Np0 -i /home/arch/pppoe-davidmiller.patch Is the patch for a different kernel? I had the same problem applying it to 2.4.7-pre8. Andrew Friedley > Michal Ostrowski writes: > > Alexey replied to my last post with some valuable comments and in > > response I have a new patch (that goes on top of David Miller's patch > > from yesterday). > > Applied to my tree, thanks. > > Later, > David S. Miller > [EMAIL PROTECTED] - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
On Fri, 20 Jul 2001, Julian Anastasov wrote: > > My understanding was that eax, ... edx are declared as > local vars and so their values can't be used out of the current > function scope, even when they are defined in inline func. Yes, but notice how we return a value. And the only way to get that value is to execute the cpuid. So obviously gcc can't drop the cpuid. And if it cannot drop it, it cannot ignore the fact that cpuid changes all the registers we say it changes. Linus - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
Julian Anastasov wrote: > > Hello, > > On Thu, 19 Jul 2001, Linus Torvalds wrote: > > > No. It's correct, because cpuid doesn't have any side effects (*), so we > > don't need to mark it volatile. gcc is free to remove it if nothing uses > > the outputs, for example. But gcc cannot (and generally does not) ignore > > outputs that _are_ specified. > > My understanding was that eax, ... edx are declared as > local vars and so their values can't be used out of the current > function scope, even when they are defined in inline func. So, I > assume they can be optimized (the fact is that they are not used) > and may be gcc forgets them. True, may be the docs do not cover > such situations but my first thought was not to explain everything > with bugs. > Well, your first thought was wrong. It is a bug. Sorry. However, your argument basically explains why adding "volatile" does work -- it keeps gcc from thinking that it can optimize away something that it otherwise couldn't. However, it's still a bug. -hpa - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
Hello, On Thu, 19 Jul 2001, Linus Torvalds wrote: > No. It's correct, because cpuid doesn't have any side effects (*), so we > don't need to mark it volatile. gcc is free to remove it if nothing uses > the outputs, for example. But gcc cannot (and generally does not) ignore > outputs that _are_ specified. My understanding was that eax, ... edx are declared as local vars and so their values can't be used out of the current function scope, even when they are defined in inline func. So, I assume they can be optimized (the fact is that they are not used) and may be gcc forgets them. True, may be the docs do not cover such situations but my first thought was not to explain everything with bugs. > Now, adding the "volatile" doesn't really make things worse, and it will > make gcc even more anal about optimizations than it normally is, which is > probably why that also hides the gcc bug. > > Note that gcc having bus in the inline asm handling is nothing new. We've > had that before, and I'm sure we'll have it again. Not very many people > use them: the kernel tends to be the heaviest user of them (with libc > probably a good second). Which is why bugs here often take time to get > fixed. It doesn't help that the documentation has been quite bad, even > misleading, at times. Agreed. It seems I have to read more docs ... > Linus > > (*) cpuid has the side effect of being a "synchronizing instruction", and > as such you can use it for some SMP ordering things etc, but as it's one > of the slowest such instructions nobody is really ever interested in using > it that way, and it doesn't have any other "architecturally visible" > effects that the compiler could care about. Regards -- Julian Anastasov <[EMAIL PROTECTED]> - 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/
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
Michal Ostrowski writes: > Alexey replied to my last post with some valuable comments and in > response I have a new patch (that goes on top of David Miller's patch > from yesterday). Applied to my tree, thanks. Later, David S. Miller [EMAIL PROTECTED] - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
Julian Anastasov wrote: > > Hello, > > On Thu, 19 Jul 2001, H. Peter Anvin wrote: > > > Julian Anastasov wrote: > > > > > > What I want to say (I could be wrong and that can't surprise me) is > > > that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs > > > use only dummy output operands... > > > > > > > Bullsh*t. One of the output operands is always a non-dummy (in > > cpuid_edx() edx is not a dummy, for example.) > > Right, and it is may be not damaged. In my first posting I > claim that cpuid_eax damages ebx (and may be ecx and edx). > Doesn't matter. gcc can't pick and choose what *effects* of an asm() statement it wants to happen -- this should be utterly obvious to anyone. As the old saying goes, you can't be half pregnant. -hpa - 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/
[PATCH] minor UFS fixups
Hello,
this patch was inspired by the Stanford checker (the report was sent out a
while ago, but I'm just getting around to submitting the patch).
They pointed out two instances of dereferencing potentially NULL pointers
in the UFS code, one of which was valid, and the other was incorrect (so
the extra check is just overhead).
The change in parse_options() is actually avoiding NULL dereference of
the "value" if a value was not given. This is a bug.
The change in ufs_check_dir_entry() removes redundant checks for "dir"
(redundant because ufs_check_dir_entry() already dereferences dir before
the checks are made, and the "dir" parameter is valid in the caller).
It also creates a local variable to avoid repeated endian swapping in
this often-used function. This is all just runtime overhead, not a bug.
Note that it doesn't _appear_ that the change to ufs_check_dir_entry()
conflicts with Al's changes in -ac, so the same patch should apply to
both 2.4.7-pre8 and 2.4.6-ac5 kernels.
Cheers, Andreas
== ufs-2.4.6-checker.diff
diff -ru linux-2.4.6.orig/fs/ufs/super.c linux-2.4.6-aed/fs/ufs/super.c
--- linux-2.4.6.orig/fs/ufs/super.c Tue May 29 13:13:21 2001
+++ linux-2.4.6-aed/fs/ufs/super.c Tue May 29 20:14:02 2001
@@ -265,6 +265,10 @@
*value++ = 0;
if (!strcmp (this_char, "ufstype")) {
ufs_clear_opt (*mount_options, UFSTYPE);
+ if (!value) {
+ printk ("UFS-fs: ufstype option needs value\n");
+ return 0;
+ }
if (!strcmp (value, "old"))
ufs_set_opt (*mount_options, UFSTYPE_OLD);
else if (!strcmp (value, "sun"))
@@ -288,6 +292,10 @@
}
else if (!strcmp (this_char, "onerror")) {
ufs_clear_opt (*mount_options, ONERROR);
+ if (!value) {
+ printk ("UFS-fs: onerror option needs value\n");
+ return 0;
+ }
if (!strcmp (value, "panic"))
ufs_set_opt (*mount_options, ONERROR_PANIC);
else if (!strcmp (value, "lock"))
diff -ru linux-2.4.6.orig/fs/ufs/dir.c linux-2.4.6-aed/fs/ufs/dir.c
--- linux-2.4.6.orig/fs/ufs/dir.c Fri Aug 11 15:29:02 2000
+++ linux-2.4.6-aed/fs/ufs/dir.cThu Jul 19 16:54:14 2001
@@ -149,34 +149,32 @@
struct ufs_dir_entry * de, struct buffer_head * bh,
unsigned long offset)
{
- struct super_block * sb;
- const char * error_msg;
- unsigned flags, swab;
-
- sb = dir->i_sb;
- flags = sb->u.ufs_sb.s_flags;
- swab = sb->u.ufs_sb.s_swab;
- error_msg = NULL;
-
- if (SWAB16(de->d_reclen) < UFS_DIR_REC_LEN(1))
+ struct super_block *sb = dir->i_sb;
+ const char *error_msg = NULL;
+ unsigned flags = sb->u.ufs_sb.s_flags;
+ unsigned swab = sb->u.ufs_sb.s_swab;
+ int rlen = SWAB16(de->d_reclen);
+
+ if (rlen < UFS_DIR_REC_LEN(1))
error_msg = "reclen is smaller than minimal";
- else if (SWAB16(de->d_reclen) % 4 != 0)
+ else if (rlen % 4 != 0)
error_msg = "reclen % 4 != 0";
- else if (SWAB16(de->d_reclen) < UFS_DIR_REC_LEN(ufs_get_de_namlen(de)))
+ else if (rlen < UFS_DIR_REC_LEN(ufs_get_de_namlen(de)))
error_msg = "reclen is too small for namlen";
- else if (dir && ((char *) de - bh->b_data) + SWAB16(de->d_reclen) >
-dir->i_sb->s_blocksize)
+ else if (((char *) de - bh->b_data) + rlen > dir->i_sb->s_blocksize)
error_msg = "directory entry across blocks";
- else if (dir && SWAB32(de->d_ino) > (sb->u.ufs_sb.s_uspi->s_ipg *
sb->u.ufs_sb.s_uspi->s_ncg))
+ else if (SWAB32(de->d_ino) > (sb->u.ufs_sb.s_uspi->s_ipg *
+ sb->u.ufs_sb.s_uspi->s_ncg))
error_msg = "inode out of bounds";
if (error_msg != NULL)
- ufs_error (sb, function, "bad entry in directory #%lu, size %Lu: %s - "
+ ufs_error (sb, function,
+ "bad entry in directory #%lu, size %Lu: %s - "
"offset=%lu, inode=%lu, reclen=%d, namlen=%d",
dir->i_ino, dir->i_size, error_msg, offset,
(unsigned long) SWAB32(de->d_ino),
- SWAB16(de->d_reclen), ufs_get_de_namlen(de));
-
+ rlen, ufs_get_de_namlen(de));
+
return (error_msg == NULL ? 1 : 0);
}
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp
Re: cpuid_eax damages registers (2.4.7pre7)
Hello, On Thu, 19 Jul 2001, H. Peter Anvin wrote: > Julian Anastasov wrote: > > > > What I want to say (I could be wrong and that can't surprise me) is > > that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs > > use only dummy output operands... > > > > Bullsh*t. One of the output operands is always a non-dummy (in > cpuid_edx() edx is not a dummy, for example.) Right, and it is may be not damaged. In my first posting I claim that cpuid_eax damages ebx (and may be ecx and edx). > -hpa Regards -- Julian Anastasov <[EMAIL PROTECTED]> - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
On Fri, 20 Jul 2001, Julian Anastasov wrote: > > In my distro (now with gcc 2.96) I have a gcc info with name "Extended > Asm", "Assembler Instructions with C Expression Operands" with the > following text: [ yes ] > What I want to say (I could be wrong and that can't surprise me) is > that the original cpuid_eax is in fact incorrect. No. It's correct, because cpuid doesn't have any side effects (*), so we don't need to mark it volatile. gcc is free to remove it if nothing uses the outputs, for example. But gcc cannot (and generally does not) ignore outputs that _are_ specified. Now, adding the "volatile" doesn't really make things worse, and it will make gcc even more anal about optimizations than it normally is, which is probably why that also hides the gcc bug. Note that gcc having bus in the inline asm handling is nothing new. We've had that before, and I'm sure we'll have it again. Not very many people use them: the kernel tends to be the heaviest user of them (with libc probably a good second). Which is why bugs here often take time to get fixed. It doesn't help that the documentation has been quite bad, even misleading, at times. Linus (*) cpuid has the side effect of being a "synchronizing instruction", and as such you can use it for some SMP ordering things etc, but as it's one of the slowest such instructions nobody is really ever interested in using it that way, and it doesn't have any other "architecturally visible" effects that the compiler could care about. - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
Julian Anastasov wrote: > > What I want to say (I could be wrong and that can't surprise me) is > that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs > use only dummy output operands... > Bullsh*t. One of the output operands is always a non-dummy (in cpuid_edx() edx is not a dummy, for example.) -hpa - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
Hello, > > kernel files that volatile solves gcc bugs. The question is whether > > the volatile is needed only as a work-around or it is needed in this > > case particulary, i.e. where the output registers are not used and are > > optimized. > > > > It certainly shouldn't; obviously, the assembly code is clearly > declaring that it is outputting multiple things. "volatile" on an > "asm" statement basically means "do this even if you don't need the > output values" (i.e. don't assume you're doing this just for the > computation), which is incorrect in this case (we *are* doing it just > for the output values, not for any side effects), but it is not really > surprising that it works around this bug. I'm now learning the inline asm but I found some interesting notes on this/similar issue: http://gcc.gnu.org/fom_serv/cache/23.html In my distro (now with gcc 2.96) I have a gcc info with name "Extended Asm", "Assembler Instructions with C Expression Operands" with the following text: --- If an `asm' has output operands, GNU CC assumes for optimization purposes the instruction has no side effects except to change the output operands. This does not mean instructions with a side effect cannot be used, but you must be careful, because the compiler may eliminate them if the output operands aren't used, or move them out of loops, or replace two with one if they constitute a common subexpression. Also, if your instruction does have a side effect on a variable that otherwise appears not to change, the old value of the variable may be reused later if it happens to be found in a register. You can prevent an `asm' instruction from being deleted, moved significantly, or combined, by writing the keyword `volatile' after the `asm'. -- follows example, etc. What I want to say (I could be wrong and that can't surprise me) is that the original cpuid_eax is in fact incorrect. All cpuid_XXX funcs use only dummy output operands and because they are not used, they are removed and not considered as changed. By using dummy vars we say "We don't care for these output values, use them in current scope only". As result, the cpuid instruction appears as not to change the 3 of the 4 registers. This explains why cpuid() behaves differently from the cpuid_XXX funcs: because the cpuid_XXX funcs declare eax ... edx as local vars, while in cpuid() they are not local and hence are not optimized. The two solutions looks valid: - to clobber the changed registers and hence not to use them as dummy output operands - already in 2.4.7pre8 - to specify volatile, which in some way avoids the default behavior to make optimizations and to remove assumptions about the used dummy output registers Of course, it is interesting why 2.95 behaves differently, may be it simply proves that I'm wrong or there is a bug/precaution introduced after 2.91.66. The key is in the "volatile" semantic. Regards -- Julian Anastasov <[EMAIL PROTECTED]> - 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/
Re: 2.4.6-ac5 and VIA Athlon chipsets
> It looks like the 2.4.6-ac5 fixed the deadlock feature with ASUS A7V133 > mobo. It's been running stable for over 24 hours now. VIA and Promise IDE > controllers are in use. Excellent. I hope soon to push the official via fix to Linus. The other good news is that I now have some official VIA contacts, so where there is a real need information should flow to the right places. Alan - 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/
Re: Errors on compiling kernel with iomega buz support
> Any ideas when this thing will be fixed in the kernel? The buz driver is obsolete. Use a -ac kernel or 2.4.7pre if you need buz support - 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/
modules/ksyms/filenames
I'm trying to export a symbol (journal_begin/end) from fs/reiserfs/journal.c. To export the symbols I added to the Makefile: export-objs := journal.o There is also a file fs/jbd/journal.c which exports symbols. It seems that the two journal.ver files in include/modules/*.ver get clobbered. Short of renaming files, is there a good solution for this? Thanks! - 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/
Re: bitops.h ifdef __KERNEL__ cleanup.
[EMAIL PROTECTED] said: > If you do not want kernel headers to be used in apps, just move them > from asm and linux into msa and xunil. Then you can simple remove all > #ifdef __KERNEL__ from them... It has been stated many times that kernel headers should not be used in apps. Renaming or moving them should not be necessary - and people would probably only start to use them again anyway. We'd see autoconf checks to find whether it's linux/private.h or xunil/private.h :) In the absence of any expectation that userspace developers will ever obey the simple and oft-repeated rule that you don't use kernel headers from userspace, the #ifdef __KERNEL__ approach would seem to be the best on offer. > P.S.: Part of ncpfs's configure.ac. I do not think that it is that > hard... I'm not very familiar with autoconf, but doesn't the snippet you pasted just check that the program compiles and links? It won't notice if you build a binary with privileged instructions in, or one which just fails to provide the correct semantics when the routine is used in a environment for which it was not designed? Where is this used in ncpfs that it makes _such_ a difference? -- dwmw2 - 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/
[PATCH] error path deallocation in ibmtr.c (246ac5)
Hi.
The following patch makes drivers/net/tokenring/ibmtr.c
call iounmap before it returns on error paths, makes it
not use check_region(), makes it check the return
of request_region and init_trdev and adds a few comment
strings on #endifs.
It applies against 246ac5 and my writing this patch was
caused by the Stanford team reporting the init_trdev
problem a while back.
--- linux-246-ac5-clean/drivers/net/tokenring/ibmtr.c Mon Jul 16 20:40:03 2001
+++ linux-246-ac5/drivers/net/tokenring/ibmtr.c Thu Jul 19 23:04:49 2001
@@ -330,7 +330,6 @@
for (i = 0; ibmtr_portlist[i]; i++) {
int ioaddr = ibmtr_portlist[i];
- if (check_region(ioaddr, IBMTR_IO_EXTENT)) continue;
if (!ibmtr_probe1(dev, ioaddr)) return 0;
}
return -ENODEV;
@@ -355,6 +354,8 @@
#ifndef MODULE
#ifndef PCMCIA
dev = init_trdev(dev, 0);
+ if (!dev)
+ return -ENOMEM;
#endif
#endif
@@ -392,6 +393,7 @@
*what we is there to learn of ISA/MCA or not TR card
*/
#ifdef PCMCIA
+ iounmap(t_mmio);
ti = dev->priv; /*BMS moved up here */
t_mmio = ti->mmio; /*BMS to get virtual address */
irq = ti->irq; /*BMS to display the irq! */
@@ -424,7 +426,12 @@
if (cardpresent == TR_ISA && (readb(AIPFID + t_mmio) == 0x0e))
cardpresent = TR_ISAPNP;
if (cardpresent == NOTOK) { /* "channel_id" did not match, report */
- if (!(ibmtr_debug_trace & TRC_INIT)) return -ENODEV;
+ if (!(ibmtr_debug_trace & TRC_INIT)) {
+#ifndef PCMCIA
+ iounmap(t_mmio);
+#endif
+ return -ENODEV;
+ }
DPRINTK( "Channel ID string not found for PIOaddr: %4hx\n",
PIOaddr);
DPRINTK("Expected for ISA: ");
@@ -442,7 +449,10 @@
waste the memory, just use the existing structure */
#ifndef PCMCIA
ti = (struct tok_info *) kmalloc(sizeof(struct tok_info), GFP_KERNEL);
- if (ti == NULL) return -ENOMEM;
+ if (ti == NULL) {
+ iounmap(t_mmio);
+ return -ENOMEM;
+ }
memset(ti, 0, sizeof(struct tok_info));
ti->mmio = t_mmio;
dev->priv = ti; /* this seems like the logical use of the
@@ -459,7 +469,7 @@
ti->turbo=1;
t_irq=turbo_irq[i];
}
-#endif
+#endif /* !PCMCIA */
ti->readlog_pending = 0;
init_waitqueue_head(&ti->wait_for_reset);
@@ -496,6 +506,7 @@
while (!readb(ti->mmio + ACA_OFFSET + ACA_RW + RRR_EVEN)){
if (!time_after(jiffies, timeout)) continue;
DPRINTK( "Hardware timeout during initialization.\n");
+ iounmap(t_mmio);
kfree(ti);
return -ENODEV;
}
@@ -609,6 +620,7 @@
default:
DPRINTK("Unknown shared ram paging info %01X\n",
ti->shared_ram_paging);
+ iounmap(t_mmio);
kfree(ti);
return -ENODEV;
break;
@@ -638,6 +650,7 @@
DPRINTK("Shared RAM for this adapter (%05x) exceeds "
"driver limit (%05x), adapter not started.\n",
chk_base, ibmtr_mem_base + IBMTR_SHARED_RAM_SIZE);
+ iounmap(t_mmio);
kfree(ti);
return -ENODEV;
} else { /* seems cool, record what we have figured out */
@@ -652,16 +665,24 @@
if (request_irq(dev->irq = irq, &tok_interrupt, 0, "ibmtr", dev) != 0) {
DPRINTK("Could not grab irq %d. Halting Token Ring driver.\n",
irq);
+ iounmap(t_mmio);
kfree(ti);
return -ENODEV;
}
/*?? Now, allocate some of the PIO PORTs for this driver.. */
/* record PIOaddr range as busy */
- request_region(PIOaddr, IBMTR_IO_EXTENT, "ibmtr");
+ if (!request_region(PIOaddr, IBMTR_IO_EXTENT, "ibmtr")) {
+ DPRINTK("Could not grab PIO range. Halting driver.\n");
+ free_irq(dev->irq);
+ iounmap(t_mmio);
+ kfree(ti);
+ return -EBUSY;
+ }
+
if (!version_printed++) {
printk(version);
}
-#endif
+#endif /* !PCMCIA */
DPRINTK("%s %s found\n",
channel_def[cardpresent - 1], adapter_def(ti->adapter_type));
DPRINTK("using irq %d, PIOaddr %hx, %dK shared RAM.\n",
--
Regards,
Rasmus([EMAIL PROTECTED])
"I begin by taking. I shall find scholars later to demonstrate my
perfect right." - Frederick (II) the Grea
2.4.7-pre8 scc.c vector latch region allocation
This patch fixes a failure in the scc.c driver to properly allocate the I/O region for the interrupt vector latch, which is present on some ham radio SCC cards, such as the PA0HZP card. Rob Turk - PE1KOX begin 666 scc_vec.patch M+2TM(&QI;G5X+F]R9R]DC@U,S!Dhttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lockup in 2.4.5-ac3 and 2.4.6-pre7 (netfilter ?)
just fyi, 2.4.7-pre8 did not cure the problem. i was able to reproduce the problem like before. this time, i switched to the log console before locking the machine up, and the oops is in fact identical to the one christian was seeing. the last line says "In interrupt handler - not syncing." which seems to explain why no syslog messages survive. regards, jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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/
Re: What are rules for acpi_ex_enter_interpreter?
Hi! > > I did NOT verified other callers of acpi_walk_namespace... And there > > is still some problem left, as although now S5 is listed as available, > > poweroff still does nothing instead of poweroff. > > Replying to myself, after following change in additon to acpi_ex_... > poweroff on my machine works. It should probably map type 0 => 0, 3 => 1 > and 7 => 2, but it is hard to decide without VIA datasheet, so change > below is minimal change needed to get poweroff through ACPI to work on my > ASUS A7V. You should printk loudly during bootup, so people know their hw is b0rken. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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/
Re: Linux 2.4.6 Configure.help incomplete :-(
Hi! > There are still a lot of help texts missing from Configure.help, > CONFIG_AIC7_BUILD_FIRMWARE to name just one example. > > I'm pretty annoyed by RELEASE versions that don't have all options > documented. If a module doesn't come with proper documentation for all > its options, drop it. Ugh? Configure.help is *very* minor thing, and it should not interfere with kernel development. It will not corrupt your data. Will not make your kernel unstable. Etc. > How is a non-hacker supposed to configure the kernel if he doesn't even > have the faintest clue about the options? How many non-hackers have you seen confused by that particular option? Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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/
Re: Tyan Thunder K7 & 2 1.2Ghz Athlon MPs
On Thu, Jul 19, 2001 at 03:24:09PM -0400, Ryan C. Bonham wrote: > I get the following messages, I will paste dmesg.log at the bottom if you > want to see it.. > mtrr: your CPUs had inconsistent fixed MTRR settings > mtrr: probably your BIOS does not setup all CPUs > >From what i gather that message can just be ignored, it stems from bios > vendors not following specs, and Linux is just making corrections.. Am I > right? The bios really isn't doing anything wrong, more like its not doing anything. It probably just isn't setting the second CPU. Linux, as far as I know, will set up the second CPU for you, and it only letting you know what's going on. > agpgart: Maximum main memory to use for agp memory: 816M > agpgart: Unsupported AMD chipset (device id: 700c), you might want to try > agp_try_unsupported=1. > agpgart: no supported devices found. > > Ok, I understand the AMD chipset on this board is new, my question here is, > how do I turn on agp_try_unsupported.. Patch the kernel? Even easier; agp_try_unsupported is a kernel command line parameter. If you're using LILO, boot with the line "linux agp_try_unsupported=1" or the like, or put "append="agp_try_unsupported=1"" in your lilo.conf file. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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/
Tyan Thunder K7 & 2 1.2Ghz Athlon MPs
Ok, I am fairly inept when it comes to kernel and what the messages mean, I was wondering if someone would explain a few messages to me.. I just compiled the 2.4.6 kernel on a new computer with the Tyan Thunder K7 and 2 1.2Ghz AMD Athlon MP CPUs, I have 1 GB of DDRAM in this computer.. I also am trying out a Adaptec 2400A IDE Raid Card... I get the following messages, I will paste dmesg.log at the bottom if you want to see it.. mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: probably your BIOS does not setup all CPUs >From what i gather that message can just be ignored, it stems from bios vendors not following specs, and Linux is just making corrections.. Am I right? agpgart: Maximum main memory to use for agp memory: 816M agpgart: Unsupported AMD chipset (device id: 700c), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. Ok, I understand the AMD chipset on this board is new, my question here is, how do I turn on agp_try_unsupported.. Patch the kernel? Thanks for the help. Ryan Dmesg.log Linux version 2.4.6 (root@PostgreSQL) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85)) #2 SMP Thu Jul 19 12:37:40 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009ec00 (usable) BIOS-e820: 0009ec00 - 000a (reserved) BIOS-e820: 000e5400 - 0010 (reserved) BIOS-e820: 0010 - 4000 (usable) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 128MB HIGHMEM available. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f7780 hm, page 000f7000 reserved twice. hm, page 000f8000 reserved twice. hm, page 0009f000 reserved twice. hm, page 000a reserved twice. On node 0 totalpages: 262144 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32768 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: TYAN Product ID: GUINNESS APIC at: 0xFEE0 Processor #1 Pentium(tm) Pro APIC version 16 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 16 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bus #0 is PCI Bus #1 is PCI Bus #2 is PCI Bus #3 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 1, trig 1, bus 3, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 1, trig 1, bus 3, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 1, trig 1, bus 3, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 1, trig 1, bus 3, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 1, trig 1, bus 3, IRQ 05, APIC ID 2, APIC INT 05 Int: type 0, pol 1, trig 1, bus 3, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 1, trig 1, bus 3, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 1, trig 1, bus 3, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 3, trig 3, bus 3, IRQ 0a, APIC ID 2, APIC INT 0a Int: type 0, pol 3, trig 3, bus 3, IRQ 0b, APIC ID 2, APIC INT 0b Int: type 0, pol 1, trig 1, bus 3, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 1, trig 1, bus 3, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 1, trig 1, bus 3, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 1, trig 1, bus 3, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 1, trig 1, bus 3, IRQ 10, APIC ID 2, APIC INT 10 Int: type 0, pol 1, trig 1, bus 3, IRQ 11, APIC ID 2, APIC INT 11 Int: type 0, pol 1, trig 1, bus 3, IRQ 12, APIC ID 2, APIC INT 12 Int: type 0, pol 1, trig 1, bus 3, IRQ 13, APIC ID 2, APIC INT 13 Int: type 0, pol 1, trig 1, bus 3, IRQ 14, APIC ID 2, APIC INT 14 Int: type 0, pol 1, trig 1, bus 3, IRQ 15, APIC ID 2, APIC INT 15 Int: type 0, pol 1, trig 1, bus 3, IRQ 16, APIC ID 2, APIC INT 16 Int: type 0, pol 1, trig 1, bus 3, IRQ 17, APIC ID 2, APIC INT 17 Lint: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 1, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=Server ro root=309 BOOT_FILE=/boot/bzImage Initializing CPU#0 Detected 1194.693 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2385.51 BogoMIPS Memo
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
Alexey replied to my last post with some valuable comments and in
response I have a new patch (that goes on top of David Miller's patch
from yesterday).
The approach here is that in case we don't have room in the skb for
PPPoE headers, we create a new one (skb2) and copy the entire thing.
If we do have space, we clone it. We always give dev_queue_xmit the
copy/clone pointer and let it free it. We then kfree_skb the original
skb depending on the return value of dev_queue_xmit (to conform to the
expectations of ppp_generic).
Michal Ostrowski
[EMAIL PROTECTED]
--- drivers/net/pppoe.c~Wed Jul 18 10:24:25 2001
+++ drivers/net/pppoe.c Thu Jul 19 14:49:36 2001
@@ -5,7 +5,7 @@
* PPPoE --- PPP over Ethernet (RFC 2516)
*
*
- * Version:0.6.7
+ * Version:0.6.8
*
* 030700 : Fixed connect logic to allow for disconnect.
* 270700 :Fixed potential SMP problems; we must protect against
@@ -25,8 +25,12 @@
* locked. (DaveM)
* Ignore return value of dev_queue_xmit in __pppoe_xmit
* or else we may kfree an SKB twice. (DaveM)
+ * 190701 :When doing copies of skb's in __pppoe_xmit, always delete
+ * the original skb that was passed in on success, never on
+ * failure. Delete the copy of the skb on failure to avoid
+ * a memory leak.
*
- * Author: Michal Ostrowski <[EMAIL PROTECTED]>
+ * Author: Michal Ostrowski <[EMAIL PROTECTED]>
* Contributors:
* Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
* David S. Miller ([EMAIL PROTECTED])
@@ -837,6 +841,7 @@
return error;
}
+
/
*
* xmit function for internal use.
@@ -849,6 +854,7 @@
struct pppoe_hdr *ph;
int headroom = skb_headroom(skb);
int data_len = skb->len;
+ struct sk_buff *skb2;
if (sk->dead || !(sk->state & PPPOX_CONNECTED))
goto abort;
@@ -864,7 +870,6 @@
/* Copy the skb if there is no space for the header. */
if (headroom < (sizeof(struct pppoe_hdr) + dev->hard_header_len)) {
- struct sk_buff *skb2;
skb2 = dev_alloc_skb(32+skb->len +
sizeof(struct pppoe_hdr) +
@@ -876,30 +881,36 @@
skb_reserve(skb2, dev->hard_header_len + sizeof(struct pppoe_hdr));
memcpy(skb_put(skb2, skb->len), skb->data, skb->len);
- skb_unlink(skb);
- kfree_skb(skb);
- skb = skb2;
+ } else {
+ /* Make a clone so as to not disturb the original skb,
+* give dev_queue_xmit something it can free.
+*/
+ skb2 = skb_clone(skb, GFP_ATOMIC);
}
- /* We may not return error beyond this point. Potentially this
-* is a new SKB and in such a case we've already freed the
-* original SKB. So if we were to return error, our caller would
-* double free that original SKB. -DaveM
-*/
-
- ph = (struct pppoe_hdr *) skb_push(skb, sizeof(struct pppoe_hdr));
+ ph = (struct pppoe_hdr *) skb_push(skb2, sizeof(struct pppoe_hdr));
memcpy(ph, &hdr, sizeof(struct pppoe_hdr));
- skb->protocol = __constant_htons(ETH_P_PPP_SES);
+ skb2->protocol = __constant_htons(ETH_P_PPP_SES);
- skb->nh.raw = skb->data;
+ skb2->nh.raw = skb2->data;
- skb->dev = dev;
+ skb2->dev = dev;
- dev->hard_header(skb, dev, ETH_P_PPP_SES,
+ dev->hard_header(skb2, dev, ETH_P_PPP_SES,
sk->protinfo.pppox->pppoe_pa.remote,
NULL, data_len);
- dev_queue_xmit(skb);
+ /* We're transmitting skb2, and assuming that dev_queue_xmit
+* will free it. The generic ppp layer however, is expecting
+* that we give back the skb in case of failure,
+* but free it in case of success.
+*/
+
+ if (dev_queue_xmit(skb2)<0) {
+ goto abort;
+ }
+
+ kfree_skb(skb);
return 1;
abort:
@@ -1049,7 +1060,6 @@
int err = register_pppox_proto(PX_PROTO_OE, &pppoe_proto);
if (err == 0) {
- printk(KERN_INFO "Registered PPPoE v0.6.5\n");
dev_add_pack(&pppoes_ptype);
dev_add_pack(&pppoed_ptype);
--- drivers/net/pppox.c~Tue Feb 13 16:15:05 2001
+++ drivers/net/pppox.c Wed Jul 18 10:27:25 2001
@@ -148,10 +148,6 @@
err = sock_register(&pppox_proto_family);
- if (err == 0) {
- printk(KERN_INFO "Registered PPPoX v0.5\n");
- }
-
return err;
}
-
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/
2.4.7pre8aa1
Diff between 2.4.7pre6aa1 and 2.4.7pre8aa1 (besides moving on top of 2.4.7pre8). Only in 2.4.7pre8aa1/: 00_do_swap_page-fix-1 Account major faults for swapins. (from -ac) Only in 2.4.7pre6aa1: 00_drop_async-io-get_bh-1 Only in 2.4.7pre8aa1/: 00_drop_async-io-get_bh-2 Rediffed for trivial reiserfs reject (reiserfs updates are included in pre8). Only in 2.4.7pre8aa1/: 00_ircomm-t39m-1 Fix for irda so that it works with my GPRS phone. Only in 2.4.7pre6aa1: 00_lvm-0.9.1_beta7-4.bz2 Only in 2.4.7pre8aa1/: 00_lvm-0.9.1_beta7-5.bz2 Rediffed for trivial rejects about updates that were just included into this patch. Only in 2.4.7pre6aa1: 00_lvm-0.9.1_beta7-4_rwsem-fast-path-1 Only in 2.4.7pre8aa1/: 00_lvm-0.9.1_beta7-5_rwsem-fast-path-2 Rediffed so we solve snapshot hash lookups with the read lock as well (low prio optimization). Also #if 0 around the _pe_lock instead of any other fix, since the pv_move with live writes going on the lv is racy anyways in lvm beta7. Only in 2.4.7pre6aa1: 00_rwsem-15 Only in 2.4.7pre8aa1/: 00_rwsem-16 Found a race in asm xchgadd algorithm, possibly mainline could be affected too, will fix it and inspect mainline ASAP. Only in 2.4.7pre6aa1: 00_sched-yield-1 Merged in mainline. Only in 2.4.7pre8aa1/: 00_via-quirks-1 VIA fixups from -ac. Only in 2.4.7pre6aa1: 10_prefetch-1 Only in 2.4.7pre8aa1/: 10_prefetch-2 Rediffed for trivial rejects. Only in 2.4.7pre6aa1/30_tux: 30_atomic-alloc-2 Only in 2.4.7pre8aa1/30_tux: 30_atomic-alloc-3 Rediffed for trivial rejects. Only in 2.4.7pre8aa1/30_tux: 32_tux-uml-1 Moved the uml part of the -aa updates in the tux directory since they are not needed when the tux patches are not applied. Only in 2.4.7pre6aa1: 40_blkdev-pagecache-5 Only in 2.4.7pre8aa1/: 40_blkdev-pagecache-6 Default opens to O_LARGEFILE in blkdev_open so that mkreiserfs doesn't need to be recompiled and we don't break backwards compatibility (can be dropped in 2.5 if we want to). Only in 2.4.7pre8aa1/: 41_blkdev-pagecache-5_drop_get_bh_async-1 When blkdev patch is applied in combination with the 00_drop_async-io-get_bh patch we must remeber to drop the get_bh from the blkdev async_io too. Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2 Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2 Moved part of it in the tux directory so it can compile without tux (in reality I got errno compilation error but it's low prio and I'll sort it out later, Jeff Dike any hint is welcome ;). URL: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.7pre8aa1/ ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.7pre8aa1.bz2 Andrea - 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/
Re: cpuid_eax damages registers (2.4.7pre7)
Followup to: By author:Julian Anastasov <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > This patch works for me too (I checked all cpuid_XXX calls). > After some thinking I produced another patch. The interesting part is > that __volatile__ solves the problem. Patch appended. I see in other > kernel files that volatile solves gcc bugs. The question is whether > the volatile is needed only as a work-around or it is needed in this > case particulary, i.e. where the output registers are not used and are > optimized. > It certainly shouldn't; obviously, the assembly code is clearly declaring that it is outputting multiple things. "volatile" on an "asm" statement basically means "do this even if you don't need the output values" (i.e. don't assume you're doing this just for the computation), which is incorrect in this case (we *are* doing it just for the output values, not for any side effects), but it is not really surprising that it works around this bug. The problem seems to be that gcc 2.91.66 thinks it can optimize away half of an indivisible operation, which cannot be called anything but a bug. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
Re: bitops.h ifdef __KERNEL__ cleanup.
On Thu, Jul 19, 2001 at 07:21:48PM +, Petr Vandrovec wrote: > Maybe because of I do not know ARM assembler? If you do not want > kernel headers to be used in apps, just move them from asm and linux > into msa and xunil. Then you can simple remove all #ifdef __KERNEL__ > from them... Why should the kernel change to please a problem minority in user space who shouldn't be including kernel headers in the first place? > It will still work. Only resulting binary will be slower. That's what > autoconf is for. If ncpfs does not compile for you, better to contact > me directly, as I'm ncpfs maintainer... No. The binary _will_ not do what you expect - these functions are not atomic in user space on all architecture types. Yes they may work, but not with the atomic side effects. You won't get this from a simple autoconf test. I'll give you credit though - you're at least checking that they appear to exist; I have come across many programs which rely on them existing, and do not check that they exist. It is these that David and myself wish to target, and this along with the general rule of "Never include kernel headers in user code", it seems to be the most appropriate solution. Now, there is a nice clean solution to your problem - bug the glibc people to provide equivalents in their library, hopefully as inline asm in the systems header files. Systems which need to do extra stuff can then have them implemented in the C library. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
Hello! > However, could we not have dev_queue_xmit behave as such (not free > frame on failure)? If you need to hold original skb, you may hold its refcnt. However, this feature inevitably results in big troubles: dev_queue_xmit() is allowed to change skb and you cannot assume anything about this. So that resuing skb dev_queue_xmit() is fatal bug not depending on anything. > The reason why I'm proposing this is that ppp_generic.c assumes that > the skb is still available after a transmission failure via pppoe. To > support the semantics of dev_queue_xmit and ppp_generic we would have > to always copy skb's inside pppoe_xmit. Then, if dev_queue_xmit fails > the original is deleted. You need not copy it. I said "clone". Nobody is allowed to touch _data_ part of skb, so that you need not to copy data. Alexey - 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/
Re: NFS Client patch
Trond Myklebust wrote: > > > " " == Chris Mason <[EMAIL PROTECTED]> writes: > > > Well, returning the last filename won't do much for filesystems > > that don't have any directory indexes, but that's besides the > > point. Could nfsv4 be better than it is? probably. Can we > > change older NFS protocols to have a linux specific hack that > > makes them more filesystem (or at least reiserfs) friendly? > > probably. > > NFSv2 and v3 have a fixed format for readdir calls. There's bugger all > you can do to change this without making the resulting protocol > incompatible with NFS. > > If you don't want Reiserfs to be NFS compatible, then fine, but I > personally don't want to see hacks to the NFS v2/v3 code that rely on > 'hidden knowledge' of the filesystem on the server. > > Cheers, > Trond > - > 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/ The current code does rely on hidden knowledge of the filesytem on the server, and refuses to operate with any FS that does not describe a position in a directory as an offset or hash that fits into 32 or 64 bits. But be calm, I am not planning on fixing this myself anytime in the next year, we have an ugly and hideous hack deployed in ReiserFS that works, for now I am just saying the folks who designed NFS did a bad job and resolutely continue doing a bad job, and if someone wanted to fix it, they could fix cookies to use filenames instead of byte offsets for those filesytems able to better use filenames than byte offsets to describe a position within a directory, and for those clients and servers who are both smart enough to understand filenames instead of cookies (able to understand the cookie monster protocol). Hans - 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/
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
[EMAIL PROTECTED] writes:
> Hello!
>
> SOme short comment on the patch:
>
>
> > - dev_queue_xmit(skb);
> > + /* The skb we are to transmit may be a copy (see above). If
> > +* this fails, then the caller is responsible for the original
> > +* skb, otherwise we must free it. Also if this fails we must
> > +* free the copy that we made.
> > +*/
> > +
> > + if (dev_queue_xmit(skb)<0) {
>
> dev_queue_xmit _frees_ frame, not depending on return value.
> Return value is not a criterium to assume anything.
>
My mistake. It seemed perfectly reasonable at 6:00 am. :-)
However, could we not have dev_queue_xmit behave as such (not free
frame on failure)? That is, could we extend dev_queue_xmit to tell it
(optionally) that we want the skb back in case of failure?
dev_queue_xmit unconditionally frees the skb in any failure mode,
which is I would venture to say that we could do this.
The reason why I'm proposing this is that ppp_generic.c assumes that
the skb is still available after a transmission failure via pppoe. To
support the semantics of dev_queue_xmit and ppp_generic we would have
to always copy skb's inside pppoe_xmit. Then, if dev_queue_xmit fails
the original is deleted.
In the common case dev_queue_xmit will not fail, and so in that case
I'd like to have to avoid making a copy of the skb.
Michal Ostrowski
[EMAIL PROTECTED]
-
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/
Re: Request for comments
On Thu, Jul 19, 2001 at 07:33:02PM +0200, Andi Kleen wrote:
> Cornel Ciocirlan <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I was thinking of starting a project to implement a Cisco-like
> > "NetFlow" architecture for Linux. This would be relevant for edge routers
> > and/or network monitoring devices.
>
> Linux 2.1+ already has such a cache in form of the rtcache since several
> years.
NeTraMet is a project that will give you NetFlow-like data. You set up traffic
meters on your routers, and gather data centrally from the meters using SNMP.
Works great.
See: http://www2.auckland.ac.nz/net/Accounting/ntm.Release.note.html
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
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/
Re: [PATCH] swap usage of high memory (fwd)
Linus Torvalds writes: > > On Thu, 19 Jul 2001, Richard Gooch wrote: > > Linus Torvalds writes: > > > Note that the unfair aging (apart from just being a natural > > > requirement of higher allocation pressure) actually has some other > > > advantages too: it ends up being aload balancing thing. Sure, it > > > might throw out some things that get "unfairly" treated, but once we > > > bring them in again we have a better chance of bringing them into a > > > zone that _isn't_ under pressure. > > > > What about moving data to zones with free pages? That would save I/O. > > Well, remember that we _are_ talking about pages that have been aged > (just a bit more aggressively than some other pages), and are not > being used. Well, under memory pressure, those pages may be considered "old" but in fact could be needed again soon. > Dropping them may well be the right thing to do, and migrating them > is potentially very costly indeed (and can cause oscillating > patterns etc horror-schenarios). If you move them, preserving the age and making sure not to evict younger pages in the new zone, that should avoid the oscillations, should it not? Besides, I've seen plenty of oscillations when paging to/from the swap device :-( > Yes, true page migration might eventually be something we have to > start thinking about for NUMA machines, but I'd really really prefer > just about any alternative. Getting a good balance would be _much_ > preferable to having to take out the sledgehammer.. I agree that a good balancing algorithm is required. I'm just suggesting that if you get to the point where you *have* to evict a page from a zone, instead of just tossing it out, move it to another zone if you can. Note that I'm not necessarily suggesting writing dirty pages to another zone instead of to swap. I was originally thinking of just moving "clean" pages (i.e. those that can be freed without the need to schedule I/O) so that potential subsequent I/O to pull them back in may be avoided. Doing proper page migration is a more complex step that needs further consideration. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
Re: Request for comments
Cornel Ciocirlan <[EMAIL PROTECTED]> writes: > Hi, > > I was thinking of starting a project to implement a Cisco-like > "NetFlow" architecture for Linux. This would be relevant for edge routers > and/or network monitoring devices. Linux 2.1+ already has such a cache in form of the rtcache since several years. -Andi - 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/
Re: [PATCH] swap usage of high memory (fwd)
On Thu, 19 Jul 2001, Linus Torvalds wrote: > Note that the unfair aging (apart from just being a natural requirement of > higher allocation pressure) actually has some other advantages too: it > ends up being aload balancing thing. Sure, it might throw out some things > that get "unfairly" treated, but once we bring them in again we have a > better chance of bringing them into a zone that _isn't_ under pressure. > > So unfair eviction can actually end up being a natural solution to > different memory pressure too Note the difference between unfair aging and unfair eviction. Unfair eviction is needed and is no problem because with fair aging this will lead to a large surplus of inactive pages in less loaded zones, increasing the chances that future allocations will end up in those zones. Unfair aging, OTOH, throws away that information, making it harder for the system to get the pressure across the zones equal again. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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/
Re: Request for comments
On Thu, Jul 19, 2001 at 06:44:52PM +0300, Cornel Ciocirlan wrote: > What this would do is keep a "cache" of all the "flows" that are passing > through the system; a flow is defined as the set of packets that have the > same headers - or header fields. For example we could choose "ip source, > ip destination, ip protocol, ip source port [if relevant], ip destination > port [ if relevant ], and maintain a cache of all distinct such > "flows" that pass through the system. The flows would have to be > "expired" from the cache (LRU) and there should be a limit on the size of > the cache. This sounds a lot like what MPLS does. I believe that someone has MPLS patches for the kernel, but I dont know who. You might want to find them and take a look. Jim - 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/
Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))
Hello!
SOme short comment on the patch:
> - dev_queue_xmit(skb);
> + /* The skb we are to transmit may be a copy (see above). If
> + * this fails, then the caller is responsible for the original
> + * skb, otherwise we must free it. Also if this fails we must
> + * free the copy that we made.
> + */
> +
> + if (dev_queue_xmit(skb)<0) {
dev_queue_xmit _frees_ frame, not depending on return value.
Return value is not a criterium to assume anything.
> + if (old_skb) {
> + /* The skb we tried to send was a copy. We
> + * have to free it (the copy) and let the
> + * caller deal with the original one.
> + */
> + skb_unlink(skb);
So, do you pass to dev_queue_xmit some skb, which is on some list?
Not a good idea. Please, clone it and submit clone, if you need to hold
original in some list.
Alexey
-
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/
Re: Request for comments
Cornel Ciocirlan <[EMAIL PROTECTED]> ecrit : [heavy linux networking rewrite in sight] > Is it useful at all ? Point b) above could be implemented in userspace > (Actually I've done a basic skeleton a while ago). Are the others worth > the trouble ? > > What do you gurus think ? * Are you sure of where the cycles are spent when routing >> 20kpps ? I have always been told that the lack of polling/batch processing kills the software router. * What against the (not widely used) CONFIG_NET_FASTROUTE ? * mpls is good Did you browse mpls at www.ietf.org (and sourceforge for the current state of mpls-linux) ? * IANAG but it looks like a wait for 2.5 project btw. -- Ueimor - 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/
Re: [PATCH] swap usage of high memory (fwd)
On Thu, 19 Jul 2001, Richard Gooch wrote: > Linus Torvalds writes: > > Note that the unfair aging (apart from just being a natural > > requirement of higher allocation pressure) actually has some other > > advantages too: it ends up being aload balancing thing. Sure, it > > might throw out some things that get "unfairly" treated, but once we > > bring them in again we have a better chance of bringing them into a > > zone that _isn't_ under pressure. > > What about moving data to zones with free pages? That would save I/O. Well, remember that we _are_ talking about pages that have been aged (just a bit more aggressively than some other pages), and are not being used. Dropping them may well be the right thing to do, and migrating them is potentially very costly indeed (and can cause oscillating patterns etc horror-schenarios). Yes, true page migration might eventually be something we have to start thinking about for NUMA machines, but I'd really really prefer just about any alternative. Getting a good balance would be _much_ preferable to having to take out the sledgehammer.. Linus - 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/
Re: bitops.h ifdef __KERNEL__ cleanup.
On 19 Jul 01 at 12:48, Russell King wrote:
>
> I totally disagree here. We already say "user space should not include
> kernel headers". Why should bitops.h be any different? Why should atomic.h
> be any different? They contain architecture specific code, yes, which
> may not work in user space.
Maybe because of I do not know ARM assembler? If you do not want
kernel headers to be used in apps, just move them from asm and linux
into msa and xunil. Then you can simple remove all #ifdef __KERNEL__
from them...
> Oh, and thanks for pointing out ncpfs breaks - I hope the authors will
> fix up their sloppy coding before Davids patch makes it into the kernel.
It will still work. Only resulting binary will be slower. That's what
autoconf is for. If ncpfs does not compile for you, better to contact
me directly, as I'm ncpfs maintainer...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
P.S.: Part of ncpfs's configure.ac. I do not think that it is that
hard...
AC_CACHE_CHECK(for working asm/atomic.h,
ncp_cv_asm_atomic_h,
AC_TRY_LINK([#define __SMP__
#include ],
[atomic_t a;
atomic_set(&a,2);
atomic_dec(&a);
if (atomic_read(&a)) {
if (!atomic_dec_and_test(&a)) {
atomic_inc(&a);
}
}],
[ncp_cv_asm_atomic_h="yes"],
[ncp_cv_asm_atomic_h="no"]
)
)
if test "$ncp_cv_asm_atomic_h" = "yes"
then
AC_DEFINE(HAVE_ASM_ATOMIC_H, 1, [Define if we have working asm/atomic.h])
fi
-
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/
Re: Inclusion of zoned inactive/free shortage patch
On Thu, 19 Jul 2001, Marcelo Tosatti wrote: > > Well, here is a patch on top of -ac5 (which already includes the first > zoned based approach patch). Looks ok. I'd like to see what the patch looks on top of a virgin tree, as it should now be noticeably smaller (no need to pas extra parameters etc). > I changed inactive_plenty() to use "zone->size / 3" instead "zone->size / > 2". > > Under _my_ tests using half of the perzone total pages as the inactive > target was too high. This is one of the reasons I'd like to see the virtgin patch - if the "/2" is too high, then that should mean that the behaviour is basically unchanged from before, right? Which would be a good sign that this kicks in gently - and I agree that "/3" sounds saner (or even "/4" - but we should double-check that the global inactive function is guaranteed to never trigger with all zones close to the "/4" target if so). I haven't checked what your changes to "total_free_shortage()" are in the -ac tree, so I don't know what the effect of that would be. Linus - 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/
Re: [PATCH] swap usage of high memory (fwd)
Linus Torvalds writes: > Note that the unfair aging (apart from just being a natural > requirement of higher allocation pressure) actually has some other > advantages too: it ends up being aload balancing thing. Sure, it > might throw out some things that get "unfairly" treated, but once we > bring them in again we have a better chance of bringing them into a > zone that _isn't_ under pressure. What about moving data to zones with free pages? That would save I/O. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
Re: [Lse-tech] Re: CPU affinity & IPI latency (FIX)_
On 17-Jul-2001 Hubertus Franke wrote: > > > This only applies only to the idle thread and it says that the idle > thread actively monitors its need_resched flag and hence will > instantly call schedule() at that point. Hence there won't be any > delay either for IPI or for waiting to return from the kernel. > > You might be right that the problem situation still arises, because > the idle_thread needs to content again for the lock. > Let me ask the otherway around, why do we HAVE to put it in ? > And if I missed something here, we put it outside the clause. Yep, we were talking about two different if-locations :) Anyway, it's right, using the poll idle we've to change the position of the assignment. - Davide - 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/
Re: 2.4.7-pre7 natsemi network driver random pauses
Wilfried Weissmann wrote:
>
> Just for curiosity, do you have those messages in our logfiles:
>
> eth0: Transmit error, Tx status register 82.
That's a 3com message, not natsemi.
And it's such a common error that it is now specially detected in the
driver:
if (tx_status == 0x82) {
printk(KERN_ERR "Probably a duplex mismatch. See "
"Documentation/networking/vortex.txt\n");
Which expands to:
Transmit error, Tx status register 82
-
This is a common error which is almost always caused by another host on
the same network being in full-duplex mode, while this host is in
half-duplex mode. You need to find that other host and make it run in
half-duplex mode or fix this host to run in full-duplex mode.
As a last resort, you can force the 3c59x driver into full-duplex mode
with
options 3c59x full_duplex=1
but this has to be viewed as a workaround for broken network gear and
should only really be used for equipment which cannot autonegotiate.
-
-
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/
Re: [PATCH] swap usage of high memory (fwd)
On Thu, 19 Jul 2001, Rik van Riel wrote: > > On Wed, 18 Jul 2001, Marcelo Tosatti wrote: > > > Still able to trigger the problem with the GFP_HIGHUSER patch applied. > > Hrrm, maybe the fact that the free target in the DMA zone is > four times higher than in the other zones has something to do > with the unbalance... No, the free target is higher for the DMA zone just to make the small zone not deplete as easily. It might make the problem slightly easier to trigger, but I think the bassic problem is real - some zones inherently have higher pressure on them, and those zones do need to be aged faster. Note that most people don't see this very much, because there are happily not that many cases where the 16MB DMA limit matters any more. These days you're more likely to start seeing the NORMAL vs HIGHMEM zone issues, where the NORMAL zone just automatically has more pressure because a lot of things like the icache/dcache can only be allocated from there. Note that the unfair aging (apart from just being a natural requirement of higher allocation pressure) actually has some other advantages too: it ends up being aload balancing thing. Sure, it might throw out some things that get "unfairly" treated, but once we bring them in again we have a better chance of bringing them into a zone that _isn't_ under pressure. So unfair eviction can actually end up being a natural solution to different memory pressure too (it obviously only works if the memory pressure isn't _too_ one-sided - if the great majority of allocations all _have_ to be to the pressure zone, the other zones obviously have no way to accept any of the extra pressure regardless of how hard they'd try). Linus - 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/
Re: 2.4.7-pre7 natsemi network driver random pauses
"Kevin P. Fleming" wrote: > > I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday > afternoon. > > The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA > KT133 (not A) motherboard using a NetGear FA312TX network card. This machine > has always run Linux just fine. After this upgrade, telnetting to my other > Linux machine (not yet upgraded) and doing long directory listings (or tar > tzvf linux-2.4.0.tar) exhibits random (and long) pauses in the output. > Switching back to 2.4.7-pre6 makes the problem disappear. Note that at this > time only the _client_ end of this connection had been upgraded to -pre7. > > I then upgraded my server as well, which is a 700 MHz Coppermine Celeron on > an SIS 630 motherboard, also using a NetGear FA312TX network card. Now this > machine exhibits the same symptoms, even when the telnet client is on a > Windows machine. > > So, it appears that one of two things happened: > > a) the natsemi driver had changes merged between -pre6 and -pre7 (not listed > in the changelogs) that had negative effects on my systems > > b) something else in the kernel caused irq/softirq/whatever random latency > to appear > > Any ideas where I should start looking? Just for curiosity, do you have those messages in our logfiles: eth0: Transmit error, Tx status register 82. Flags; bus-master 1, dirty 20979238(6) current 20979242(10) Transmit list 1f659290 vs. df659260. 0: @df659200 length 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea status 000105ea I had those with 2.4.3-pre6. They disappeared in 2.4.4. Another user reported the same on lkml with different kernel versions. Wilfried - 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/
Re: kernel lockup in 2.4.5-ac3 and 2.4.6-pre7 (netfilter ?)
[christian, i'm quoting a message of yours below. maybe this is of interest to you, so i'm cc:ing] Thomas wrote: > > Jörn Nettingsmeier wrote: > > > hello brad, hello netfilter people ! > > Brad Chapman wrote: > > > >>Were you able to rescue any console output from the hard > >> lockup; > >> i.e. you did a klogd -c 7 to capture _everything_ the kernel > >> spit out? > >> If you were able to, could you send them to the list, please? > >> > > i have just reproduced the lockup with the klogd setting you > > suggested, but no entries at all have survived. > > however, it has been pointed out to me that my lockups might be > > caused by a faulty pppoe module (i'm using a dsl connection) > > rather > > than netfilter. > > it looks like i need to investigate a little further on pppoe... > > let's see what the lkml archive has to say. > > thanks for all the helpful replies. i will keep you posted if i > > can > > solve this problem. > > > Hi, > i can't help you exactly, but i also use T-Dsl and also there it > come to hangup's ( sometimes kernel panic ) > At the moment i get it off, i switched the debug mode on and log > all the crap in an file ( hoped i find the error ) > but after debug on there was no more hangup. I'm sure it is an bug > in the pppoe system, wich come to work > when the T* have trouble and send defekt packets. The ground i > think it have to do with defekt packets is > that other frinds with dsl under windoff told me that they also > have on the same time many disconnects. > > Cu thomas i found someone else's oops report on lkml, and this is exactly the one i'm seeing, although i can't save it for lack of a serial console: > christian wrote on lkml: > > PROBLEM: Kernel Panics since i switched to T-DSL, using > masquadering. Supposed to be > fixed in 2.4.5pre9 ? > > virtual address 8ba7 > *pde = > Oops = > CPU = 0 > EIP = 0010:[] > EFLAGS: 00010202 > > eax: c1569940 ebx: 8ba7 ecx: edx: 00068ba7 > esi: c1b5ce80 edi: c15697e0 ebp: 0060 esp: c0e41dd4 > ds: 0018 es: 0018 ss: 0018 > > Process dnetc (pid: 2152, stackpage=c0e41000) > > Stack: ff00 c01c976b c1b5ce80 ff00 c1b5ce80 c01c9d53 > c1b5ce80 c11fa800 > c1b5ce80 000e c1b5ce80 ffe6 c01cc667 c1b5ce80 > 0020 0004 > c1979b20 000e c01d0cdd c1b5ce80 0001 > c1b5ce80 c01dabf0 > > Call Trace: [] [] [] > [] [] > [] [] > [] [] [] > [] [] > [] [] [] > > ^ f or 1 ? > (that's the f in the third entry, for those not using fixed > width fonts :) > [] [] [] > [] [] > [] [] [] > [] > > Code: 8b 1b 8b 42 70 83 f8 01 74 0b f0 ff 4a 70 0f 94 c0 84 c0 > 74 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing. i can trigger this bug by simply typing ctrl-c in an ftp or ssh session from a machine on the local (masqueraded) network to the internet. some folks have blamed the ppp/pppoe code, but after further testing it does seem to be netfilter-related somehow, since i cannot reproduce the oops on the router itself with iptables modules unloaded. it only happens on a machine on the local network when masqueraded via the router. does this assumption make sense ? i was pointed to a ppp patch from lkml, but it seems to be relevant only to starting/stopping a ppp device. (message "[PATCH] ppp_generic.c - kfree(ppp) called twice") right now, i'm trying 2.4.7-pre8, it has a load of ppp related patches. it's still compiling atm. getting confused... jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://icem-www.folkwang-hochschule.de/~nettings/ http://www.linuxdj.com/audio/lad/ - 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/
Re: Request for comments
++ 19/07/01 18:44 +0300 - Cornel Ciocirlan: > a) more efficient packet filtering. After a cache entry is created for a > flow, we apply the ACLs for the packet and associate the action with the > flow. All subsequent packets belonging to the same flow will be > dropped/accepted without re-appying the packet filtering rules I'm seeing an identification problem arise here. You have to be able to identify packets in a flow robustly, and you have to be able to spot packets trying to fake it. I dont see any way in which you will be able to avoid the packet filtering rules here. -- Crutcher<[EMAIL PROTECTED]> GCS d--- s+:>+:- a-- C$ UL$ L+++$> !E PS+++ PE Y+ PGP+> R-(+++) !tv(+++) b+() G+ e> h+>++ r* y+>*$ - 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/
Re: Inclusion of zoned inactive/free shortage patch
On Thursday 19 July 2001 01:42, Daniel Phillips wrote: > Yes. The inactive shortage needs to be a function of the length of > the inactive_dirty queue rather than just the amount that free pages > is less than some fixed minimum. Oops, it already is, good :-] > The target length of the > inactive_dirty queue in turn can be a function of the global free > shortage (which is where the minimum free numbers get used) ditto, it's already that way... > and the transfer rate of the disk(s). This we don't do, and afaics, this is the only way to get stability across a really wide range of loads, and on system configurations we can't possibly pre-tune for. > Again, experimental - without careful > work a feedback mechanism like this could oscillate wildly. It's > most probably the way forward in the long run though. > > -- > Daniel - 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/
Re: 2.4.6 and netboot
> On Thursday 19 July 2001 06:26 am, Wakko Warner wrote: > > I'm using a kernel that is dd'd to a floppy to net boot linux on random > > machines. I noticed that 2.4.6 won't get it's IP from the server (it won't > > even attempt it). 2.4.4 works > > > > If any more info is needed, just ask. > > Sine 2.4.4 I have been unable to make ipconfig automagically go, and I think > that this configuration is not supported. At least, with my limited > knowledge of how ipconfig works you must to pass: 'ipconfig=dhcp', or > ipconfig='bootp' to the kernel at boot time. I built a LILO disk, but > I think that syslinux would work. Also, I did eventually successfully get an > Xterminal running. > After 2.4.4 ipconfig was changed to the ipconfig= style of behaviour. I > don't know why, but someone does. I think it has to do with implementation > cahnges to allow for modularized NIC's to use ipautoconfig. This seems > insane that functionality was cut in order to do this. Hmm, maybe I'll check the diff on 2.4.5 to see what was done. > Also, I have been unable to make bootp work for nfsboot, but I suspect my > bootp server - not the kernel. > > BACK to the point. Since 2.4.5 I have had to use lilo, and add a line that > says 'nfs=[all that stuff] ipconfig=dhcp' =( -- Lab tests show that use of micro$oft causes cancer in lab animals - 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/
Re: 2.4.6 and netboot
> > I'm using a kernel that is dd'd to a floppy to net boot linux on random > > machines. I noticed that 2.4.6 won't get it's IP from the server (it won't > > even attempt it). 2.4.4 works > > > > If any more info is needed, just ask. > > It sounds as though you left out CONFIG_IP_PNP in the kernel > configuration. netboot works fine under 2.4.6 for me # grep CONFIG_IP_PNP /usr/src/linux/wdist/2.4.6/.config CONFIG_IP_PNP=y # CONFIG_IP_PNP_DHCP is not set CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # Nope, didn't. 2.4.4 works just fine, 2.4.6 doesn't. I also have no way of doing kernel parameters since it's a raw kernel. -- Lab tests show that use of micro$oft causes cancer in lab animals - 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/
2.4.7-pre7 natsemi network driver random pauses
I upgraded two machines here from 2.4.7-pre6 to 2.4.7-pre7 yesterday afternoon. The first machine I upgraded, my workstation, is a 1GHz Athlon on a VIA KT133 (not A) motherboard using a NetGear FA312TX network card. This machine has always run Linux just fine. After this upgrade, telnetting to my other Linux machine (not yet upgraded) and doing long directory listings (or tar tzvf linux-2.4.0.tar) exhibits random (and long) pauses in the output. Switching back to 2.4.7-pre6 makes the problem disappear. Note that at this time only the _client_ end of this connection had been upgraded to -pre7. I then upgraded my server as well, which is a 700 MHz Coppermine Celeron on an SIS 630 motherboard, also using a NetGear FA312TX network card. Now this machine exhibits the same symptoms, even when the telnet client is on a Windows machine. So, it appears that one of two things happened: a) the natsemi driver had changes merged between -pre6 and -pre7 (not listed in the changelogs) that had negative effects on my systems b) something else in the kernel caused irq/softirq/whatever random latency to appear Any ideas where I should start looking? - 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/
Re: 2.4.6 and netboot
On Thursday 19 July 2001 06:26 am, Wakko Warner wrote: > I'm using a kernel that is dd'd to a floppy to net boot linux on random > machines. I noticed that 2.4.6 won't get it's IP from the server (it won't > even attempt it). 2.4.4 works > > If any more info is needed, just ask. Sine 2.4.4 I have been unable to make ipconfig automagically go, and I think that this configuration is not supported. At least, with my limited knowledge of how ipconfig works you must to pass: 'ipconfig=dhcp', or ipconfig='bootp' to the kernel at boot time. I built a LILO disk, but I think that syslinux would work. Also, I did eventually successfully get an Xterminal running. After 2.4.4 ipconfig was changed to the ipconfig= style of behaviour. I don't know why, but someone does. I think it has to do with implementation cahnges to allow for modularized NIC's to use ipautoconfig. This seems insane that functionality was cut in order to do this. Also, I have been unable to make bootp work for nfsboot, but I suspect my bootp server - not the kernel. BACK to the point. Since 2.4.5 I have had to use lilo, and add a line that says 'nfs=[all that stuff] ipconfig=dhcp' good luck. js - 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/
__alloc_pages X-order allocation failed.
Hello linux-kernel, I'm trying to get stable running kernel from 2.4 series for about 3 months now, I thought it should become stable up to this time but it still not at least in VM area. I'm Testing various kernels from Linus, Alan, Andrea as well as some other patches provided but still: I have no kernel which runs stable - I always have __alloc_pages errors in kernel logs and after while system completely dies with different things. I have about 30 systems I try to kernel start to work. They contain 1-2GB of memory, some of them are SMP. Some have swapping on software raid1, which I thought is the reason, but it's not even putting swap on a raw partition does not help. Traces show quit different places for __alloc_pages to fail there is really NO out of memory condition - several hundreds of megabytes are in cache. The main purpose for these systems is MYSQL database. So I'm asking if there is any way to make kernel running more stable? May be some workarounds exists - For example may be I can increase number of reserved buffers and so on ? -- Best regards, Peter mailto:[EMAIL PROTECTED] - 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/
Re: ReiserFS / 2.4.6 / Data Corruption
On Thu, Jul 19, 2001 at 12:02:59PM +1000, Steve Kieu wrote: > --- Erik Mouw <[EMAIL PROTECTED]> wrote: > On > > FUD. I've been using reiserfs on quite some systems > > Probably !. I said just from my computer, :-) > > Reiserfs uses system resources more than others. > Perfomance is ok (not as far more or less than JFS) > but after using for a while, some mysterious things > happen ; for example, the ini file of some program is > changed wihtout any reason. For example I run mc and > make it learn all keys, and pause when executing a > command ; After reboot, sometimes all these setting > are lost, some times not. It still happen with XFS > though but never see in ext2, ext3 (now I am using) That sounds more like hardware problems to me. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
Request for comments
Hi, I was thinking of starting a project to implement a Cisco-like "NetFlow" architecture for Linux. This would be relevant for edge routers and/or network monitoring devices. What this would do is keep a "cache" of all the "flows" that are passing through the system; a flow is defined as the set of packets that have the same headers - or header fields. For example we could choose "ip source, ip destination, ip protocol, ip source port [if relevant], ip destination port [ if relevant ], and maintain a cache of all distinct such "flows" that pass through the system. The flows would have to be "expired" from the cache (LRU) and there should be a limit on the size of the cache. What can we use the cache for: a) more efficient packet filtering. After a cache entry is created for a flow, we apply the ACLs for the packet and associate the action with the flow. All subsequent packets belonging to the same flow will be dropped/accepted without re-appying the packet filtering rules b) traffic statistics. When expiring a flow in the cache we could send a special "messagge" to a user-space process with the * flow caracteristics (ip src,ip dest etc) * total number of packets that were associated with this flow * flow start timestamp, flow last-activity timestamp * avg pkts/second while the flow was active * total bytes transmitted for this flow c) we could make routing decisions by looking at the flow cache, eg when we first create the flow we look into the routing table and save the index of the output interface in the flow cache. Subsequent packets matching the flow will not cause a search through the routing table. d) prevent denial-of-service by configuring for example automatic filtering of a flow that matches more than some-high-value pps (Most flows will probably be 1000 pps max, while packet floods can be 5k-25k easily) Problems: - some overhead will be added, however if we implement a) and c) above we can reduce it. d) will also make the system perform better under high load. - we need to come up with a pretty efficient data structure to search through it very quickly - if we route 20k pps, too much overhead will kill us. I was thinking of a hash table with AVL trees instead of linked lists, which I think the buffer cache is using; other options: splay trees maybe useful ?) - in all cases we'll need something like an expiry thread that actively removes inactive flows from the cache Is it useful at all ? Point b) above could be implemented in userspace (Actually I've done a basic skeleton a while ago). Are the others worth the trouble ? What do you gurus think ? Kind regards, Cornel. - 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/
Re: 1GB system working with 64MB
Edouard Soriano wrote: > > Hello Folks, > > Environment: linux 2.2.16smp > RedHat 7.0 > My problem are the 63892K If you upgrade to the 2.2.19 kernel, this will just work, no need for extra options. (Red Hat also has a 2.2.19 kernel available as errata release for 7.0) - 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/
[Q]: kernel: __alloc_pages: 3-order allocation failed.
Hi, I'm running a dual PIII, 3GB box (2.4.0.SuSE and 2.4.4.SuSE) getting the error above, despite the fact the ~700MB are still available. In conjunction w/ the log message I get fork failures (out of memory)... I'm running 5500 processes having devices open and doing IP. Many of the processes are pppds. Is there any way to allow the kernel using more of the available memory (tweaking constants etc.)... [limits have been raised...] Thanks for the help, Immanuel -- Till Immanuel Patzschke mailto: [EMAIL PROTECTED] interNetwork AG Phone: +49-(0)611-1731-121 Bierstadter Str. 7 Fax:+49-(0)611-1731-31 D-65189 Wiesbaden Web:http://www.internetwork-ag.de - 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/
Re: 2.4.6 and netboot
On Thu, 19 Jul 2001, Wakko Warner wrote: > I'm using a kernel that is dd'd to a floppy to net boot linux on random > machines. I noticed that 2.4.6 won't get it's IP from the server (it won't > even attempt it). 2.4.4 works > > If any more info is needed, just ask. It sounds as though you left out CONFIG_IP_PNP in the kernel configuration. netboot works fine under 2.4.6 for me -- Ryan Sweet <[EMAIL PROTECTED]> Atos Origin Engineering Services http://www.aoes.nl - 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/
Re: 1GB system working with 64MB
Edouard Soriano <[EMAIL PROTECTED]> wrote: > I remember there is a solution to turn around this problem forcing LILO to > configure 1GB saying, I think but not sure: > > append='memory=1024' > > I searched in the lilo doc for memory parameter definition, but as being > coverd by append parameter I found nothing. "mem=" is documented in the kernel documentation (...linux/Documentation/i386/boot.txt): mem= is an integer in C notation optionally followed by K, M or G (meaning << 10, << 20 or << 30). This specifies to the kernel the memory size. [snip] HTH, Ray -- Does Kibo SEE the FNORDS? - 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/
Re: 1GB system working with 64MB
Add this: append="mem=1024M" to your lilo boot profiles. ... 2.4 correctly detects memory size more often than 2.2.16 ... - Original Message - From: "Edouard Soriano" <[EMAIL PROTECTED]> Subject: 1GB system working with 64MB > Hello Folks, > Environment: linux 2.2.16smp > RedHat 7.0 > > My problem are the 63892K - 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/
1GB system working with 64MB
Hello Folks, Environment: linux 2.2.16smp RedHat 7.0 I am setting up a system with 1GB RAM recongized by the BIOS during power-on procedure. This system having troubles, I set a top command and with surprise I got this status: 4:33pm up 4:42, 3 users, load average: 4.18, 2.01, 1.09 125 processes: 123 sleeping, 2 running, 0 zombie, 0 stopped CPU0 states: 9.1% user, 9.0% system, 8.0% nice, 80.1% idle CPU1 states: 20.0% user, 6.1% system, 20.1% nice, 72.0% idle Mem:63892K av, 62480K used,1412K free, 15076K shrd,5192K buff Swap: 514040K av, 260556K used, 253484K free 11804K cached My problem are the 63892K I remember there is a solution to turn around this problem forcing LILO to configure 1GB saying, I think but not sure: append='memory=1024' I searched in the lilo doc for memory parameter definition, but as being coverd by append parameter I found nothing. Question 1: Do you have an idea about the reason Linux is using 64MB ? Question 2: Is this append command correct to turn out this problem ? Question 3: Where can I found informations about append variables wich are related in fact with modules parameters ? How to find on source code which module will read the memory parameter ? Thanks in advance. Bye - 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/
