* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: John Bradford @ 2003-01-10 17:02 UTC (permalink / raw)
To: Alan Cox; +Cc: fverscheure, linux-kernel, marcelo, andre
In-Reply-To: <1042219407.31848.71.camel@irongate.swansea.linux.org.uk>
> > And by the way how are powered off the IDE drives ?
> > Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before
> > powering off the drive with cache enabled or you will enjoy lost
> > data.
>
> We always issue standby or sleep commands to a drive before powering
> off which means the cache flush thing should never have been an
> issue.
I experienced drives spinning back up after they had been flushed on
powerdown, which is not necessarily wrong, (I.E. I never noticed any
data loss), but it's not ideal. Can't we do:
* Standby
* Flush
* Standby
or is there a reason not to? I know there were discussions about the
right order to do the standyby and flush, and as far as I remember, we
never reached a conclusion :-).
John.
^ permalink raw reply
* [2.4.21-pre3] BUG: IDE DMA doesn't work w/ x86 HighMem
From: Ross Biro @ 2003-01-10 17:04 UTC (permalink / raw)
To: linux-kernel
Configure the 2.4.21-pre3 kernel with IDE and Highmem and when DMA is
attempted you get a BUG from asm-i386/pci.h line 155 called from
drives/ide/ide-dma.c line 282.
From the looks of it, the IDE driver has not been highmem enabled, but
does get a high-mem device queue.
This is easily reproduced on a dual proc P3 with 2 Gigs of ram.
Ross
^ permalink raw reply
* Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PREFIX is non-empty
From: Linus Torvalds @ 2003-01-10 17:03 UTC (permalink / raw)
To: Rusty Russell; +Cc: Richard Henderson, Miles Bader, linux-kernel
In-Reply-To: <20030110102144.4BE3C2C113@lists.samba.org>
On Fri, 10 Jan 2003, Rusty Russell wrote:
>
> Yep. Maximum length of obsolete parameter name in current kernel:
> seq_default_timer_resolution (28 chars).
Don't do this. Make the limit fixed, and check it.
Linus
^ permalink raw reply
* Re: BLKBSZSET still not working on 2.4.18 ?
From: John Bradford @ 2003-01-10 17:08 UTC (permalink / raw)
To: Alan Cox; +Cc: ludovic.drolez, linux-kernel
In-Reply-To: <1042218525.31848.40.camel@irongate.swansea.linux.org.uk>
> > I'm trying to backup a partition on an IDE drive which has an odd number
> > of sectors (204939). With a stock open/read you cannot access the last
> > sector, and that why I tried the BLKBSZSET ioctl to set the basic read
> > block size to 512 bytes. I verified the writen value with BLKBSZGET
> > ioctl, but I still cannot read this last sector !
>
> Its a known 2.4 limitation. The last odd sector isnt normally used by
> anything so it has never been a big issue (except with EFI partition
> data).
Didn't some really obscure IBM drives use it for something internally,
and shortly after everybody else had to stop using it incase they
overwrote the custom data at the end of an IBM disk, or am I thinking
of something else?
John.
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Dave Jones @ 2003-01-10 17:06 UTC (permalink / raw)
To: Alan Cox; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <1042219147.31848.65.camel@irongate.swansea.linux.org.uk>
On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote:
> Most of the drivers still don't build either.
or still lack 2.4 fixes.
> - The stuff that is destined for the bitbucket is marked in Config and people
> agree it should go
What's happening with the OSS drivers ?
I'm still carrying a few hundred KB of changes from 2.4 for those.
I'm not going to spent a day splitting them up, commenting them and pushing
to Linus if we're going to be dropping various drivers.
> - It passes Cerberus uniprocessor and smp with/without pre-empt
I think this should wait until at least some more of the 2.4 changes
come forward. Most of those are security issues and the likes, but there
are a few driver corner cases too.
> Otherwise everyone wil rapidly decide that ".0-pre" means ".0 as in Windows"
> at which point you've just destroyed your testing base.
agreed.
> Given all the new stuff should be in, I'd like to see a Linus the meanie
> round of updating for a while which is simply about getting all the 2.4 fixes
> and the 2.5 driver compile bugs nailed, and if it doesn't fix a compile bug
> or a logic bug it doesn't go in.
Seconded.
> No more "ISAPnP TNG" and module rewrites please
Absolutly. Lets try and get 2.6 out the door _this_ year.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [TRIVIAL] [PATCH 1 of 3] Fix errors making Docbook documentation
From: Linus Torvalds @ 2003-01-10 17:06 UTC (permalink / raw)
To: Alan Cox; +Cc: Rusty Russell, Linux Kernel Mailing List, Craig Wilkie
In-Reply-To: <1042199637.28469.52.camel@irongate.swansea.linux.org.uk>
On 10 Jan 2003, Alan Cox wrote:
>
> I thought bitkeeper had an "exclude" function ?
So? Somebody needs to send me a doc patch, and in the meantime I'll take
partial fixes.
I'm not excluding patches just because somebody else hasn't done a good
job.
Linus
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Dave Jones @ 2003-01-10 17:08 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: William Lee Irwin III, torvalds, linux-kernel
In-Reply-To: <Pine.LNX.4.50.0301101139000.7163-100000@montezuma.mastecende.com>
On Fri, Jan 10, 2003 at 11:41:48AM -0500, Zwane Mwaikambo wrote:
> > other needs more investigation), and another that falls on its
> > face after 10 minutes idle uptime. My p4-ht desktop box is the only one
> > that runs 2.5 without any problems.
>
> Thats interesting, i have a laptop experiencing the same symptoms, i'll be
> looking at it over the weekend.
This is exactly the sort of thing I meant. There are still problems out
there which a lot of people haven't reported, yet when they see someone
else with that problem, suddenly the 'me too's come in.
I'm hoping the bugzilla will help out for corelating these as it starts to get
used more.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [2.5.55, PCI, PCMCIA, XIRCOM]
From: Valdis.Kletnieks @ 2003-01-10 17:13 UTC (permalink / raw)
To: Jochen Hein; +Cc: linux-kernel
In-Reply-To: <87znq9ynz4.fsf@jupiter.jochen.org>
[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]
On Fri, 10 Jan 2003 17:21:51 +0100, Jochen Hein <jochen@jochen.org> said:
>
>
> With 2.4.20 the xircom_cb driver works perfectly on my Thinkpad 600.
> Loading the driver with 2.5.55 for my IBM ethernet card I get:
> Jan 10 11:35:24 gswi1164 kernel: PCI: Device 01:00.0 not available because of
resource collisions
The problem is (as I understand it) that drivers/pcmcia/cardbus.c ends up
not allocating the onboard ROM resource for some cards before trying to
enable it. I've attached a patch that worked for me on 2.5.52, although
said patch caused a lot of discussion here about the *right* way to do it
(even *I* admit it's a hack) - and I've seen a report it causes an OOPS
on 2.5.53. I've not tried it on post-52, but I had a -54 kernel OOPS
right around that point in bootup (right after IDE and somewhere in PCI
init). Haven't chased that one at all...
/Valdis
[-- Attachment #1.2: pcmcia.patch --]
[-- Type: application/x-patch , Size: 492 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* PrPMC800 - Restarting PPC7-Bug without a reset
From: Anders Blomdell @ 2003-01-10 17:05 UTC (permalink / raw)
To: linuxppc embedded
Hi,
We have a number of PrPMC800 systems that are to be run in NON-MONARCH mode.
Unfortunately they hang indefinitely if I tries to do a [card] reset (full
system reset works). This means that it is impossible to use the Harrier
chip to get the board to do a proper reset.
Therefore I need some way to restart PPC7-Bug without doing a hardware
reset (in the belief that PPC7-Bug will setup the card in a useful state).
The naive attempt to do a "g fff00100" [jumping to the reset exception
handler in flash] from the PPC7-Bug prompt, of course failed miserably, and
so did my attempts to simulate a system reset by the following code:
lis r0,0xfff0 ; Flash reset vector lives at 0xfff00100
ori r0,r0,0x0100
li r9,0x40 ; Use exception prefix = 0xfffn_nnnn
mtmsr r9 ; Make msr contain exception prefix bit
mtsrr0 r0 ; Make rfi return to 0xfff00100
mtsrr1 r9 ; Make msr after rfi contain exception prefix bit
sync
rfi ; Simulate a reset
Anybody that has some good idea of what could be done?
Regards
Anders Blomdell
------------------------------------------------------------------------------
Anders Blomdell
Department of Automatic Control Email: anders.blomdell@control.lth.
se
Lund Institute of Technology Phone: +46 46 222 4625
Box 118, S-221 00 Lund, Sweden Fax: +46 46 138118
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Valdis.Kletnieks @ 2003-01-10 17:13 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
In-Reply-To: <20030110161212.GA11193@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
On Fri, 10 Jan 2003 17:12:12 +0100, Andi Kleen <ak@suse.de> said:
>
> > So the end-result of the discussion is, "What should really happen here?"
> > and "What, if anything, do you want me to do?"
>
> IMHO best would be to get rid of /proc/*/wchan and keep the kallsyms
> lookup slow, simple and stupid.
And replace the current /proc/*/wchan functionality with what?
(Note that saying "read the System.map file from userspace" doesn't *quite*
work, as I may be running a kernel that doesn't have System.map installed
someplace easily findable. At the moment my /boot partition has 6 assorted
vmlinuz-\(*\) files, only 4 of which have System.map-\1 files matching).
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [parisc-linux] new gcc-default for hppa
From: Randolph Chung @ 2003-01-10 17:09 UTC (permalink / raw)
To: jsoe0708; +Cc: parisc-linux, debian-hppa
In-Reply-To: <3E1AA8D500000A9A@ocpmta8.freegates.net>
> I do notice that unstable debian for i386 switch (or will very soon) gcc-default
> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
> kernel with this because of pb encounter with network connection)
yes:
tausq@auric:~$ madison gcc|grep unstable
gcc | 2:3.1-1 | unstable | hurd-i386
gcc | 3:3.2.2-0 | unstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
randolph
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Robert Love @ 2003-01-10 17:15 UTC (permalink / raw)
To: Hugh Dickins
Cc: William Lee Irwin III, Andi Kleen, Daniel Ritz, linux-kernel,
daniel.ritz
In-Reply-To: <Pine.LNX.4.44.0301101628460.1434-100000@localhost.localdomain>
On Fri, 2003-01-10 at 11:34, Hugh Dickins wrote:
> Indeed! I think that was Andi volunteering :-}
> But we should let rml defend his wchan.
Well, of course I want to keep it - but I am biased :)
I think its a simple export that gives us a neat feature. Additionally,
from the procps perspective, it saves us from having to parse System.map
for each process. In fact, it means we do not need a System.map at all
for any procps functionality.
I guess Linus at least mildly liked it too, since he merged it.
But if its such a performance crippling item perhaps it does need to be
removed (or somehow restricted).
I do agree that, if possible, wchan should be kept simple... so, is
everyone else for the removal of /proc/pid/wchan ? :-(
Robert Love
^ permalink raw reply
* Re: [PATCH] SCSI Core patches
From: James Bottomley @ 2003-01-10 17:06 UTC (permalink / raw)
To: Mike Anderson; +Cc: Luben Tuikov, linux-scsi
In-Reply-To: <20030108211306.GG1112@beaverton.ibm.com>
I got around to looking at the patch.
I think the idea of slab allocation for Scsi_Cmnds is generally worth the
effort. There are several issues with the current patch, though:
1) The command for the device has to be allocated in space that respects the
dma_mask for the device (on a non MMIO bus). Pretty much for scsi, this
translates to using GFP_DMA as the allocation flag if unchecked_isa_dma is
set. GFP_DMA has to be passed in at kmem_cache_create time. We therefore
probably need the capacity to use a different kmem_cache on a per Scsi_Host
basis and the ability to set up a GFP_DMA kmem_cache if a host with
unchecked_isa_dma appears.
2) scsi_get_command takes the host lock when obtaining a command from it's
free_list. Unfortunately, scsi_get_command looks to be called from places
(like the prep_fn) where the lock is already held => deadlock.
3) The free_list employs all the list machinery for potentially storing
multiple commands, but in practice it looks like it only ever stores one of
them. Is there a plan to make this free_list size tuneable (probably tuneable
per device)?
James
^ permalink raw reply
* Any paper on Journaling algorithm?
From: bmoon @ 2003-01-10 17:07 UTC (permalink / raw)
To: Hans Reiser; +Cc: reiserfs-list
In-Reply-To: <3E194161.1070306@namesys.com>
Hello!
I am investigating on the Journaling from the Reisersfs source code.
However, it is not easy to understand. I could not find any good reference
on the Journaling.
Please guide me to the good reference or paper on the journaling algorithm.
Thanks,
Bo
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: Matthew Wilcox @ 2003-01-10 17:08 UTC (permalink / raw)
To: jsoe0708; +Cc: Randolph Chung, parisc-linux
In-Reply-To: <3E1AA8D500000902@ocpmta8.freegates.net>
On Fri, Jan 10, 2003 at 11:51:41AM +0100, jsoe0708@tiscali.be wrote:
> PS: with ext3 (which I use) problem I hesitate to install 2.4.20 and waiting
> for 2.4.21 and evms, jfs, xfs support for this system)
um, you use the data=ordered mount option (or whatever it was)?
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: [parisc-linux] new gcc-default for hppa
From: Randolph Chung @ 2003-01-10 17:09 UTC (permalink / raw)
To: jsoe0708; +Cc: parisc-linux, debian-hppa
In-Reply-To: <3E1AA8D500000A9A@ocpmta8.freegates.net>
> I do notice that unstable debian for i386 switch (or will very soon) gcc-default
> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
> kernel with this because of pb encounter with network connection)
yes:
tausq@auric:~$ madison gcc|grep unstable
gcc | 2:3.1-1 | unstable | hurd-i386
gcc | 3:3.2.2-0 | unstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
randolph
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2003-01-10 17:11 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Ingo Molnar, Jamie Lokier, Ulrich Drepper, davej, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0301101202020.1743-100000@gra-lx1.iram.es>
On Fri, 10 Jan 2003, Gabriel Paubert wrote:
>
> We cannot rely either on userspace not setting NT bit in eflags. While
> it won't cause an oops since the only instruction which ever depends on
> it, iret, has a handler (which needs to be patched, see below),
> I'm absolutely not convinced that all code paths are "NT safe" ;-)
It shouldn't matter.
NT is only tested by "iret", and if somebody sets NT in user space they
get exactly what they deserve.
> For example, set NT and then execute sysenter with garbage in %eax, the
> kernel will try to return (-ENOSYS) with iret and kill the task. As long
> as it only allows a task to kill itself, it's not a big deal. But NT is
> not cleared across task switches unless I miss something, and that looks
> very dangerous.
It _is_ cleared by task-switching these days. Or rather, it's saved and
restored, so the original NT setter will get it restored when resumed.
> I'm no Ingo, unfortunately, but you'll need at least the following patch
> (the second hunk is only a typo fix) to the iret exception recovery code,
> which used push and pops to get the smallest possible code size.
Good job.
Linus
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Andi Kleen @ 2003-01-10 17:19 UTC (permalink / raw)
To: Valdis.Kletnieks, Andi Kleen; +Cc: linux-kernel
In-Reply-To: <200301101713.h0AHDmLK010383@turing-police.cc.vt.edu>
On Fri, Jan 10, 2003 at 12:13:48PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 10 Jan 2003 17:12:12 +0100, Andi Kleen <ak@suse.de> said:
> >
> > > So the end-result of the discussion is, "What should really happen here?"
> > > and "What, if anything, do you want me to do?"
> >
> > IMHO best would be to get rid of /proc/*/wchan and keep the kallsyms
> > lookup slow, simple and stupid.
>
> And replace the current /proc/*/wchan functionality with what?
Ctrl-Rollen (or whatever the key is called on your keyboard) on the console,
like in all previous linux releases.
Note /proc/*/wchan is not in 2.4.
Also you still have WCHAN in ps, just not a full backtrace.
-Andi
^ permalink raw reply
* Re: [PATCH]Re: spin_locks without smp.
From: Manfred Spraul @ 2003-01-10 17:19 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Maciej Soltysiak, William Lee Irwin III
Alan wrote:
>On Fri, 2003-01-10 at 13:04, William Lee Irwin III wrote:
>> Okay, what I'm getting here is that the UP case already has preempt
>> disabled b/c the locks are taken in IRQ context?
>
>The tx/timeout path isnt always in IRQ context.
>
It is.
tx and timeout are both called at BH context with the dev_xmit spinlock
held. See Documentation/networking/netdevices.txt
What about
disable_irq();
spin_lock(&np->lock);
That's what 8390.c uses, no need for an #ifdef.
--
Manfred
^ permalink raw reply
* Re: SSH doesnt properly logout
From: Toby Fisher @ 2003-01-10 17:15 UTC (permalink / raw)
To: axel; +Cc: linux-admin
In-Reply-To: <20030110140855.GB2417@neon.pearbough.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 10 Jan 2003 axel@pearbough.net wrote:
> Hi linux admins,
>
> I'm observing some strange behaviour concerning ssh and logging out from a
> ssh connection when I put a process in background on the remote side.
> For instance I do the following:
>
> * I start a gcc compilation on the remote terminal
> make bootstrap >& build.log &
> Then it goes into background.
>
> * Now I "logout" but do not return to my local terminal, now there is only a
> blank screen with the cursor in the upper left side.
>
> Can somebody help me please in understand this behaviour or rather help me
> fix it?
Have you tried using the nohup command?
For example
nohup make
You will then see something like
"Appending output to nohup.out"
You can specify the file for nohup to use.
This is probably the proper way to achieve what you want, though haven't
tested it myself to see if it gets over the problem you report, though I
have used it on occasions so I can start builds and then log out before
going to bed.
Kind regards.
- --
Toby Fisher Email: toby@tjfisher.co.uk
Tel.: +44(0)1480 417272 Mobile: +44(0)7974 363239
ICQ: #61744808
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/
iD8DBQE+Hv+yKl9qIwuqk+IRAtw2AKCaD8qaHnZ4/085/sewbYtkwJTR+wCeOhrY
1EdRWfST/SPU3FCLqMuYNLo=
=Pdq7
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Jeff Garzik @ 2003-01-10 17:25 UTC (permalink / raw)
To: Dave Jones, Alan Cox, William Lee Irwin III, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <20030110170625.GE23375@codemonkey.org.uk>
On Fri, Jan 10, 2003 at 05:06:25PM +0000, Dave Jones wrote:
> On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote:
> What's happening with the OSS drivers ?
> I'm still carrying a few hundred KB of changes from 2.4 for those.
> I'm not going to spent a day splitting them up, commenting them and pushing
> to Linus if we're going to be dropping various drivers.
I've been updating the via audio every now and again.
If sound/oss is staying for 2.6.0, we might as well merge the 2.4.x
changes.
Jeff
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Alan Cox @ 2003-01-10 18:12 UTC (permalink / raw)
To: Jens Axboe
Cc: Andre Hedrick, fverscheure, Linux Kernel Mailing List,
Marcelo Tosatti
In-Reply-To: <20030110164834.GM843@suse.de>
On Fri, 2003-01-10 at 16:48, Jens Axboe wrote:
> In the barrier patches, I just used drive->quiet to supress ide_error()
> complaining too much (on cache flushes, too). Whether that's per-drive
> of per-hwif entity, dunno...
Commands are queued per hwif so it doesn't actually matter I suspect.
BTW do you plan to fix up the oopses in the tcq code or should I just mark
it disabled for anyone who has the time to finish the job ? There are a
whole pile of drivers that fail with tcq - mostly because they have custom
dma end functions
^ permalink raw reply
* Re: SSH doesnt properly logout
From: Toby Fisher @ 2003-01-10 17:18 UTC (permalink / raw)
To: Carl; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20030110144956.01f95bb0@pop3.demon.co.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 10 Jan 2003, Carl wrote:
<snip>
> Try running it with a nohup
>
> nohup make bootstrap >& build.log &
nohup does not require the trailing &, and you could tell nohup to use
build.log without the redirection, see the nohup man page.
Kind regards.
- --
Toby Fisher Email: toby@tjfisher.co.uk
Tel.: +44(0)1480 417272 Mobile: +44(0)7974 363239
ICQ: #61744808
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/
iD8DBQE+HwBQKl9qIwuqk+IRAqzoAKDuIVNME7/o+5p6GMCk8wpLI1bIuQCfYhGn
MD46Reyu0SW1P8YxOBcMPYw=
=+RKp
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: BLKBSZSET still not working on 2.4.18 ?
From: Alan Cox @ 2003-01-10 18:14 UTC (permalink / raw)
To: John Bradford; +Cc: ludovic.drolez, Linux Kernel Mailing List
In-Reply-To: <200301101708.h0AH8nUS013550@darkstar.example.net>
On Fri, 2003-01-10 at 17:08, John Bradford wrote:
> Didn't some really obscure IBM drives use it for something internally,
> and shortly after everybody else had to stop using it incase they
> overwrote the custom data at the end of an IBM disk, or am I thinking
> of something else?
Something else - EFI uses the last sector for partitioning as one example.
Drives do have protected private areas but they are shielded from normal
use for obvious reasons
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Alan Cox @ 2003-01-10 18:16 UTC (permalink / raw)
To: Dave Jones
Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20030110170625.GE23375@codemonkey.org.uk>
On Fri, 2003-01-10 at 17:06, Dave Jones wrote:
> What's happening with the OSS drivers ?
> I'm still carrying a few hundred KB of changes from 2.4 for those.
> I'm not going to spent a day splitting them up, commenting them and pushing
> to Linus if we're going to be dropping various drivers.
I'd hope they would go away but it seems that will be post 2.6. The
drivers do seem to mostly work in 2.5.x. I'm meaning the stuff that
doesn't compile and nobody gives a damn about.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.