I am running 2.0.32 and am facing a very strange problem
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda3 289797 282977 0 100% /
/dev/hda1 8040 5868 2172 73% /drive/c
/dev/hda5 97536 90960 6576 93% /drive/5
/dev/hda6 16955 3930 13025 23% /drive/e
/dev/hda7 109608 105752 3856 96% /drive/f
I get the above result from 'df' which tells me that though
8 MB is free... nothing is available. I checked and found out
that I can increase and decrease Used, by adding and deleting
files, but Available never changes... also some programs like
sendmail check only the available and quit. In sendmail I solved
the problem by asking it to look for space more than -1 bytes.
however some other proggies are failing becuase of this. Though
I will get latest kernel installed, I am still trying to think
what caused this problem. I am using 2.0.32 from the time it
was released on the net... and this is the first time I am facing
this problem.
Thanking you
Royans
> "A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru> writes:
>>: The problem is (2) requires quite a bit of work and I never got around to
>>: doing it. But I do think it's the Right Way.
>>
>>I believe it's right way. At least in 2.1.79 the attempt
>>to invert this order (only for link layer headers) is made and
>>I see no reasons why not to complete this inversion.
>>
>>The only problem is that we must allocate skb with necessary room
>>at head now. SACKS (and extension headers) would require to overincrease
>>MAX_HEADER space.
>
> As I recall, changes to MAX_HEADER used imply nasty side effects on
> broken network drivers. I hope this issue is dead for a while now though.
>
>>: Or am I horribly wrong? Also is anybody working on the SACK?
>>
>>Dave said something about SACKS, but I do not know details.
>>Andy, I suspect you already did it. I mean not SACKS, but inversion
>>of header filling order. IPv6 exthdrs seems to be much more natural
>>in this case.
>
> About SACK, I was working on it before I disappeared for 5 months to
> start my life over again. I'm back on-line now and hoping to contribute
> to getting the TCP code up to speed again. As has been noted I had
> started making room for SACK in the code but did not finish.
> I have a little bit more code sitting around in the wings, but I'm
> not sure how well it fits with the changes that have happened to the
> kernel lately. I'd be happy to talk this over if anyone wants to pitch in
> or take over on the SACK front.
>
> About the header construction, Andi perhaps you could say if you did
> invert the filling order (ala BSD) to construct the header just before
> sending out the packet? If it's not to bad as far as the sockbuf
> stuff goes this might give us the last little bit needed to be able to
> do SACK somewhat cleanly.
>
> Also, while I'm doing scatter shot questions. Alan, you mentioned some
> problems with TCP window scaling and such. Can you be more specific?
> I got the code in but never really got much testing feedback before I
> disappeared, and haven't really heard anything since. I'll take a knife
> to the code anyway and see what it's doing, but if you could point me
> at a known problem, or something that should specifically be fixed it
> would be a bit faster.
>
> Cheers,
>
> - --
> Eric Schenk www: http://www.loonie.net/~eschenk
> email: eschenk@loonie.net, eschenk@rogers.wave.ca
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>
> Date: Mon, 9 Feb 1998 09:34:02 +0100
> Subject: Re: extended paritions are evil.
>
>> When devfs was first described, one of the features was that certain
>> devices which had "serial numbers" such as most hard disk file
>> systems, would be represented as a /dev/volume/serial... which would be
>> a symbolic link to the full address. Then the fstab entries could
>> optionally reference a device independent of the hardware position.
>
> I believe this is currently not implemented. I'm also not sure whether
> this should be a kernel-mode feature; the kernel would need to know
> where each file system puts the serial number. File systems vary
> greatly in this respect.
>
> Regards,
> Martin
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Pavel Machek <pavel@elf.ucw.cz>
> Date: Sun, 8 Feb 1998 22:11:15 +0100
> Subject: Re: Laptops (APM) & 0040 crashes
>
> Hi, Stephen!
>
>> OK, I wouldn't want to leave you stranded on FreeBSD :-) Can you try
>> the following patch for me. It is against 2.0.33. I can only say that
>> it doesn't stop my APM enabled desktop from running - I don't have a
>> machine with an APM BIOS with the 0x40 access bug.
>
> Did you make sure that GDT is not overfilled? (I.e. 12+NUM_TASKS being
> more than you can fit in GDT?)
>
>> What I should have said is that M$ and Intel have made up another
>> standard for power management. APM is still used by everyone,
>> but ACPI(?) is on the horizon.
>
> ACPI is not as broken as names of its creators would suggest.
>
>> +
>> + /*
>> + * Set up a segment that references the real mode segment 0x40
>> + * that extends up to the end of page zero (that we have reserved).
>> + * This is for buggy BIOS's that refer to (real mode) segment 0x40
>> + * even though they are called in protected mode.
>> + */
>> + set_base(gdt[APM_40 >> 3],
>> + 0xc0000000 + ((unsigned long)0x40 << 4));
>> + set_limit(gdt[APM_40 >> 3], 4096 - (0x40 << 4));
>
> NIce. It might be nice to do this only iff certain config option
> (CONFIG_I_PROMISE_I_WILL_NOT_BUY_NOTEBUG_WITH_BROKEN_BIOS_AGAIN), so
> that users are aware of problem and so there is still light pressure
> to manufacturers to fix their code.
>
> Also, 2.1.X patch might be nice: this is not likely to be adopted in
> 2.0.X, but IMO it could well go into 2.1.86 [Well- if it works. Did it
> actually help somebody so far?]
>
> Pavel
>
> - --
> I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
> Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: tigran_aivazian@dsti.co.uk
> Date: Mon, 9 Feb 1998 08:49:55 +0000
> Subject: Re[2]: OFFTOPIC: Linux Kernel is Too Good.
>
> This is a multipart message in MIME format
>
> - --------------InterScan_NT_MIME_Boundary
> Content-Type: text/plain; charset=ISO-8859-1
> Content-transfer-encoding: quoted-printable
>
>>Of course, it's only scientific if you do the same sort of test
>>under varying OS's on the same machine=2E =2E =2E
>
>
>>But seeing the thinkpad whup up on the IBM put a grin on my head=2E
>
> Of course, I did that as well, I just forgot to give the numbers=2E On
> P200 running DOS it took 23 seconds for 1 instance and 229 seconds for
> 10 instances (in 10 DOS boxes with background=3Don)=2E
>
> **********************************************************************
> DST International Tel:+44 181 390 5000 www=2Edstinternational=2Eco=2Eu=
> k=20
>
> This message and any attachments to it is intended only for the=20
> individual or company to which it is addressed and may contain=20
> information which is privileged, confidential or prohibited from=20
> disclosure or unauthorised use=2E If the recipient of this=20
> transmission is not the intended recipient, or the employee or agent=20
> responsible for delivering such materials to the intended recipient,=20
> you are hereby notified that any use, any form of reproduction,=20
> dissemination, copying, disclosure, modification, distribution and/or=20
> publication of this e-mail message or its attachments other than by=20
> its intended recipient is strictly prohibited by the sender=2E =20
>
> If you have received it in error, please notify us immediately by=20
> telephone on the number above and destroy the message and all copies=20
> in your possession=2E
> **********************************************************************
>
>
> - --------------InterScan_NT_MIME_Boundary--
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> End of linux-kernel-digest V1 #1571
> ***********************************
>
> To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
> in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If you want
> to subscribe something other than the account the mail is coming from,
> such as a local redistribution list, then append that address to the
> "subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
> A non-digest (direct mail) version of this list is also available; to
> subscribe to that instead, replace all instances of "linux-kernel-digest"
> in the commands above with "linux-kernel".
---- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu