Re: Cleanup kbuild for aic7xxx
"Justin T. Gibbs" wrote: > > >> >Users don't have to manually select "rebuild firmware". They can > >> >rely on the generated files already in the aic7xxx directory. This > >> >is why the option defaults to off. > > > >For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have > >had to manually select this for a 7892 controller. Without manually > >selecting it, it guarantees boot failure. I don't know if this is due to > >the SGI modifications or not. The real problem I found is that during > >boot failure, there was no meaningful debug message. > > I don't know why your kernel source is out of sync. I will have to > go pull down the 2.4.5 and 2.4.6 trees and see if some portion of > my patches never made it into those trees. It also looks like the > comment section for this option didn't make it into my 2.4.4 and above > patches. I'll correct this on this on Monday. Here's the relevent > info. Do you have any comments on what would make it more useful? > > +Build Adapter Firmware with Kernel Build > +CONFIG_AIC7XXX_BUILD_FIRMWARE > + This option should only be enabled if you are modifying the > + firmware source to the aic7xxx driver and wish to have the > + generated firmware include files updated during a normal > + kernel build. The assmebler for the firmware requires > + lex and yacc or their equivalents, as well as the db v1 > + library. You may have to install additional packages or > + modify the assmebler make file or the files it includes > + if your build environment is different than that of the > + author. I would add a note to try without it at first, but if bootup starts normally, then hangs in what seems like a controller or filesystem failure of a scsi drive, try to enable the option. (this would give some hint about debugging an aic7xxx failure, regardless of error messages) D. Stimits, [EMAIL PROTECTED] > > >Missing firmware rebuild is fatal for my system, SMP x86 with integrated > >7892. Messages and config menu information is inadequate, it requires a > >bit of pounding the head on the wall to figure it out. > > It is hard to make the kernel driver give a reasonable message for every > possible error that running with incompatible components may cause. > > -- > Justin - 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: [RFC] Early flush (was: spindown)
On Saturday 23 June 2001 01:25, Daniel Kobras wrote:
> On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
> > Daniel Phillips writes:
> > > I'd like that too, but what about sync writes? As things stand now,
> > > there is no option but to spin the disk back up. To get around this
> > > we'd have to change the basic behavior of the block device and
> > > that's doable, but it's an entirely different proposition than the
> > > little patch above.
> >
> > I don't care as much about sync writes. They don't seem to happen very
> > often on my boxes.
>
> syslog and some editors are the most common users of sync writes. vim,
> e.g., per default keeps fsync()ing its swapfile. Tweaking the configuration
> of these apps, this can be prevented fairly easy though. Changing sync
> semantics for this matter on the other hand seems pretty awkward to me. I'd
> expect an application calling fsync() to have good reason for having its
> data flushed to disk _now_, no matter what state the disk happens to be in.
> If it hasn't, fix the app, not the kernel.
But apps shouldn't have to know about the special requirements of laptops.
I've been playing a little with the idea of creating a special block device
for laptops that goes between the vfs and the real block device, and adds the
behaviour of being able to buffer writes in memory. In all respects it would
seem to the vfs to be a disk. So far this is just a thought experiment.
> > > You know about this project no doubt:
> > >
> > >http://noflushd.sourceforge.net/
> >
> > Only vaguely. It's huge. Over 2300 lines of C code and >560 lines in
> > .h files! As you say, not really lightweight. There must be a better
> > way.
>
> noflushd would benefit a lot from being able to set bdflush parameters per
> device or per disk. So I'm really eager to see what Daniel comes up with.
> Currently, we can only turn kupdate either on or off as a whole, which
> means that noflushd implements a crude replacement for the benefit of
> multi-disk setups. A lot of the cruft stems from there.
Yes, another person to talk to about this is Jens Axboe who has been doing
some serious hacking on the block layer. I thought I'd get the early flush
patch working well for one disk before generalizing to N ;-)
> > Also, I suspect (without having looked at the code) that it
> > doesn't handle memory pressure well. Things may get nasty when we run
> > low on free pages.
>
> It doesn't handle memory pressure at all. It doesn't have to. noflushd only
> messes with kupdate{,d} but leaves bdflush (formerly known as kflushd)
> alone. If memory gets tight, bdflush starts writing out dirty buffers,
> which makes the disk spin up, and we're back to normal.
Exactly. And in addition, when bdflush does wake up, I try to get kupdate
out of the way as much as possible, though I've been following the
traditional recipe and having it submit all buffers past a certain age. This
is quite possibily a bad thing to do because it could starve the swapper.
Ouch.
--
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: Cleanup kbuild for aic7xxx
>> >Users don't have to manually select "rebuild firmware". They can >> >rely on the generated files already in the aic7xxx directory. This >> >is why the option defaults to off. > >For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have >had to manually select this for a 7892 controller. Without manually >selecting it, it guarantees boot failure. I don't know if this is due to >the SGI modifications or not. The real problem I found is that during >boot failure, there was no meaningful debug message. I don't know why your kernel source is out of sync. I will have to go pull down the 2.4.5 and 2.4.6 trees and see if some portion of my patches never made it into those trees. It also looks like the comment section for this option didn't make it into my 2.4.4 and above patches. I'll correct this on this on Monday. Here's the relevent info. Do you have any comments on what would make it more useful? +Build Adapter Firmware with Kernel Build +CONFIG_AIC7XXX_BUILD_FIRMWARE + This option should only be enabled if you are modifying the + firmware source to the aic7xxx driver and wish to have the + generated firmware include files updated during a normal + kernel build. The assmebler for the firmware requires + lex and yacc or their equivalents, as well as the db v1 + library. You may have to install additional packages or + modify the assmebler make file or the files it includes + if your build environment is different than that of the + author. >Missing firmware rebuild is fatal for my system, SMP x86 with integrated >7892. Messages and config menu information is inadequate, it requires a >bit of pounding the head on the wall to figure it out. It is hard to make the kernel driver give a reasonable message for every possible error that running with incompatible components may cause. -- Justin - 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: High system CPU% in dual CPU System
At 23:25 Uhr -0400 22.06.2001, Dan Maas wrote: > > CPU0 states: 19.2% user, 32.0% system, 0.0% nice, 48.2% idle >> CPU1 states: 20.4% user, 40.1% system, 0.0% nice, 38.3% idle > >> What can I do to find out what the CPUs are doing during "system" time? > >Try 'ps -ax' and see if any process has a large TIME (cumulative CPU time). >I suspect you may just be seeing a kernel idle process (e.g. kapm-idled), >which is nothing to worry about. Hi Dan, thanx for the hint. I could identify one of my scripts as cause of the problem and will now have a closer look at its periodic activity.. Ingo - 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/
[RFC] Early flush: new, improved
The early-flush patch I posted a couple of days ago had the virtue of being simple and functional, but not optimal for all loads, particularly sporadic loads that are neither continously heavy or light. Today's patch is not a lot more complex, but works quite a lot better. The new kflush algorithm has the following goals: 1) Start writing as soon as there is something to write 2) But while there is other traffic, wait as long as possible 3) Keep the IO queues full 4) But not too full 5) Be efficient about all of the above As with the previous patch, I'm running the kflush loop every 100 milliseconds, in other words, I'm using a polling strategy as opposed to event-oriented. I thought about that carefully and decided the polling approach would be both more efficient (because otherwise the events would have to have been triggered from performance-critical places like __mark_dirty and blk_started_io) and more robust (with a timed loop it's easier to prove assertions about realtime performance). The reason for goal (3) is twofold: to give the elevator something to chew on, and to make sure that the queue doesn't empty out before the next iteration of kflushd has a chance to fill it up. Goal (4) is there to make sure that the system doesn't get stalled doing an early flush when the next surge in demand for disk bandwidth comes along. As before, I'm measuring the actual disk traffic rather than trying to predict it, say by looking at the memory pressure. I'm still lumping together all disks into one bandwidth number, an unspeakably crude thing to do, but until someone sends me a nice test machine, I'm going to continue to do that. ;-) This time around I'm measuring not only the queued_sectors IO backlog, but the submitted_sectors submission rate as well, the latter being incremented in blk_started_io. As a slight optimization I can count the retired_sectors as well and replace queued_sectors wherever it's used by: (submitted_sectors - retired_sectors) Submitted_sectors will eventually wrap, so the rule is: it's only valid to look at the difference between two sampled values, much as we do with jiffies. Theory of operation: - Every 100 ms kflush checks that there were no new io submissions in the previous 100 ms period. If so, and the queued IO backlog is below some threshold, it initiates an early flush - Regardless of what else happens, kflush initiates a flush at intervals no greater than the usual time prescribed by the bdflush parameters. - The flush (flush_dirty_buffers) makes sure all buffers older than the time prescribed by the bdflush parameters are submitted, then, if the IO backlog is less than some threshold higher than kflush's trigger threshold, submitts some younger buffers opportunistically, so that the disk bandwidth is not wasted. As a side effect of not wasting the bandwidth we get some improvement in data safety, and in my opinion at least, a system that feels nicer - no disk write 'echo'. Also, there's the thing that started me on this, spindown 5 seconds early on my laptop. One subtle detail I mentioned earlier is concerned with not allowing kflush to beome confused by the traffic it generates itself - this doesn't count as traffic for the purpose of determining whether the opportunistic flush should be done. It turned out to be possible to hande this nasty-sounding accounting requirement with just one add: submitted1 += sync_old_buffers(); To make this work I changed the accounting units used by sync_old_buffers from 'buffers' to 'sectors'. However, I didn't want to have to go retune the VM (not that it's necessarily tuned very well at the moment ;-) so I pass back the sectors count from sync_old_buffers when it's called from kflush, otherwise, the buffers count. Naturally, this ugliness can't be allowed to live. Performance - Kernel compilation is almost a worst case for the early flush because of the frequent load changes and extensive use of temporary files. Nonetheless, in the one benchmark I ran, the measured time was virtually identical with and without the early flush. (Actually, 7 seconds faster with the early flush, but that is not statistically significant.) Early flush: real13m40.838s user10m38.460s sys 0m51.700s Vanilla kernel: real13m47.850s user12m23.610s sys 0m35.030s The patch is against 2.4.5. To apply: cd /your/source/tree patch b_flushtime = jiffies + bdf_prm.b_un.age_buffer; + bh->b_dirtytime = jiffies; refile_buffer(bh); } @@ -2524,12 +2524,17 @@ as all dirty buffers lives _only_ in the DIRTY lru list. As we never browse the LOCKED and CLEAN lru lists they are infact completly useless. */ -static int flush_dirty_buffers(int check_flushtime) + +static unsigned low_queued_goal = 200; +static unsigned high_queued_goal = 400; + +static int
Re: Is this part of newer filesystem hierarchy?
Luigi Genoni wrote:
>
> Again i am confused.
>
> /usr/bin/ld is linker at compilation time, at it works how i told in
> second part
> of my mail, (just try to compile it, it comes with binutils,
> ftp.kernel.org/pub/linux/devel/binutils).
>
> /lib/d-2.2.X.so is what you are talking about.
> So should i think os an hack to ld-2.2.3.so ??
The RH 7.1 comes with:
:~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
elf_i386
i386linux
elf_i386_glibc21
The glibc rpm is version 2.2.2-10.
>
> to see how it works loock at /usr/bin/ldd, it's an interesting script.
>
> I can understand why old glibc 2.1 is not isered in the directories
> where ldconfig has to loock to create its db for loader, but there should
> be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> subdirectories)
> for glibc 2.2, since it is necessary at compilation
> time.
There is *no* /usr/i386-xxx except for:
/usr/i386-glibc21-linux/
No glibc22 version exists.
> This do not change the problem which is related to /lib/ld-2.2.X.so.
> doing a strings /lib/ld-2.XXX
> you will find also
>
> info[19]->d_un.d_val == sizeof (Elf32_Rel)
> info[20]->d_un.d_val == 17
> /lib/
> /usr/lib/
> {ORIGIN}
> {PLATFORM}
> expand_dynamic_string_token
> dl-load.c
"i686" is visible on a line by itself, but so are i386, i486, and i586.
The full path of /lib/i686/ is not mentioned anywhere. So it looks like
strings of /lib/ld-2* does not offer any hints as to how the i686
subdirectory is being chosen without it being specified anywhere else. I
think this will end up just being one of those mysteries, and the boot
software coder will have to find some non-trivial workaround. It sounds
like the /lib/i686/ path was hardcoded in the linker when it was
compiled, which means there are no simple config file checks.
D. Stimits, [EMAIL PROTECTED]
>
> this is the interesting section of the output. This way you can check for
> an hack to the loader, but I think to something else instead of an hack.
>
> I do not have a red hat here around, since i do prefer another style for
> my linux systems, so i cannot check by person.
>
> Luigi Genoni
>
> On Fri, 22 Jun 2001, D. Stimits wrote:
>
> > Luigi Genoni wrote:
> > >
> > > I do not know if this is a new filesystem hierarchy, it should not be,
> > > at less untill lsb finishes all discussion (anyway it is similar to lsb
> > > standard). Your mail is a little confusing for me. Let's see if i can
> > > clarify my ideas.
> > >
> > > On Thu, 21 Jun 2001, D. Stimits wrote:
> > >
> > > > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > > > differently than just /lib/. Here is the structure I found:
> > > >
> > > > /lib/ has:
> > > > libc-2.2.2.so (hard link)
> > > > libc.so.6 (sym link to above)
> > > >
> > > > A new directory appears, /lib/i686/ (uname -m is i686):
> > > > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > > > libc.so.6 (sym link to hard link in this directory)
> > > >
> > > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > > > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > > > while the 1.2 MB version is stripped.
> > > >
> > > > Here is the peculiar part that I need to find out about. My
> > > > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > > > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > > > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > > > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > > > the i686 directory is being checked if it is not listed in ld.so.conf
> > > > and not part of any LD path variable? I am using a non-Redhat kernel
> > > > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > > > kernel itself. My ld version:
> > > excuse, but if you do something like,
> > > ldd /bin/ls
> > >
> > > what do you get, which libc is loaded?
> >
> > :~# ldd /bin/ls
> > libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
> > libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
> >
> > The i686 subdirectory version is visible to the linker. I don't know
> > how.
> >
> > >
> > > have you got a file like /etc/ld.so.preload??
> >
> > No. Nor are any preload or LD environment variables set. Something
> > Redhat has done is making the i686 subdirectory visible. Maybe ld
> > searches recursively?
> >
> > > basically you can use the stripped glibc (faster), but then,
> > > if you have troubles and you need to debug, just set the preload file,
> > > or use LD_PRELOAD variable to use
> > > the non stripped library. In princip it is not a stupid idea,
> > > not that i like it, but it is not stupid.
> >
> >
GPIB support
I'm doing a project which port a component testing program in DOS which use GPIB to linux Does the Linux kernel support GPIB? I find a linux gpib driver in the linux lab project http://www.llp.fu-berlin.de/ but the newest version is release at 1999 and i wonder if it still under development.. Moreover,it is for kernel 1.2.x or 2.0.x and i wonder it will still work on linux 2.4.x or not - 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: Cleanup kbuild for aic7xxx
"J . A . Magallon" wrote: > > On 20010623 Keith Owens wrote: > > > >>What again are you trying to fix? It looks to me like you are simply > >>trying to make it harder for people actually working on the aic7xxx > >>driver to have proper dependencies. > > > >The patch still works for anybody changing the aic7xxx firmware or the > >aicasm code. Any change to the generated files or the aicasm files now > >forces a rebuild, the option is not required. Only people changing > >aic7xxx firmware are affected, instead of everybody. > > > > It is easier than that. Nobody should be rebuilding the firmware apart > from driver mantainers. If driver version in 2.4.5 is 6.1.13, that version > includes a certain firmware in .h format and that is all. Apart from > this, the author (Justin) can make available in his web page one other > package for driver testers or developers including aicasm and firmware > source. But that should not be in the kernel tree. > If there are updates to the firmware, just send the patch for .h files > to kernel mantainers and/or lkml, as everybody does. > > This is easier, doesn't it ? It would cause problems for me. Perhaps it is an issue of XFS filesystem patches, rather than the regular kernel, I don't know what it modifies relative to aic7xxx. But so far all of my recent test kernels will fail to complete boot correctly if rebuild firmware is not used. D. Stimits, [EMAIL PROTECTED] > > -- > J.A. Magallon # Let the source be with you... > mailto:[EMAIL PROTECTED] > Mandrake Linux release 8.1 (Cooker) for i586 > Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686 > - > 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/ - 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: Cleanup kbuild for aic7xxx
Keith Owens wrote:
>
> On Fri, 22 Jun 2001 13:39:45 -0600,
> "Justin T. Gibbs" <[EMAIL PROTECTED]> wrote:
> >>The existing build process for aic7xxx on Linux has several problems.
> >>
> >>* Users have to manually select "rebuild firmware". Relying on users
> >> to perform any action other than make *config is unacceptable. It is
> >> far too error prone.
> >
> >Users don't have to manually select "rebuild firmware". They can
> >rely on the generated files already in the aic7xxx directory. This
> >is why the option defaults to off.
For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
had to manually select this for a 7892 controller. Without manually
selecting it, it guarantees boot failure. I don't know if this is due to
the SGI modifications or not. The real problem I found is that during
boot failure, there was no meaningful debug message.
>
> You rely on a timestamp check to tell the users "suggest you rebuild
> firmware". That timestamp check is inherently unreliable when files
> are both generated and shipped.
>
> >>* Rebuilding the firmware requires lex, yacc and libdb. Not everybody
> >> has these installed.
> >
> >Then they shouldn't check the box "rebuild firmware".
>
> See above. Users think they need to turn on the firmware build, then
> complain when it breaks.
>
> >>* The check for which libdb to use assumes that the presence of a db.h
> >> is enough, but the overlap between glibc-devel and dbx-devel packages
> >> means that finding a db.h is not enough, you have to confirm that the
> >> corresponding libdb exists.
> >
> >Such is Linux. Those who understand what it means to rebuild the
> >firmware will have the necessary tools, check the box in config,
> >and have it work.
But there is insufficient menu dialog associated with rebuild firmware.
>
> Wrong. Such is the way it _used_ to be. As the use of Linux expands,
> more and more people are building their own kernels without knowing all
> the internals. This is good, we get more users. But kernel build code
> can no longer assume that anybody building a kernel is automatically an
> expert.
>
> >>* It checks if the firmware is up to date by comparing the timestamps
> >> on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
> >> aic7xxx.reg. Alas, when a patch hits those files there is no
> >> guarantee which order the files are listed in the patch so the final
> >> timestamp order is unreliable. diff lists files in alphabetical
> >> order but other source repository systems can generate patches in any
> >> order. This is a problem for all generated files, not just aic7xxx.
> >
> >So you might get a harmless warning if you haven't checked the box. This
> >is not fatal and I have yet to hear one complaint about it.
Missing firmware rebuild is fatal for my system, SMP x86 with integrated
7892. Messages and config menu information is inadequate, it requires a
bit of pounding the head on the wall to figure it out.
>
> http://marc.theaimsgroup.com/?l=linux-kernel=99124017310488=2
> was fatal, you even replied to it.
>
> >>* Shipping files which are also overwritten by users causes problems
> >> for source control systems and can cause spurious differences when
> >> generating patches. This is a problem for all generated files, not
> >> just aic7xxx.
> >
> >Those using revision control should know how to use revision control.
> >The driver is developed under revision control and the current setup
> >causes me no grief. Of course, I don't keep the generated files in
> >revision control because there is no benefit in doing so.
>
> Users take patches from Linus or Alan Cox which include the generated
> patches and add the patches to local source repositories. That
> includes the generated files. If it comes from Linus or AC it is a
> "master" copy. End users do not have the luxury of excluding the
> generated files from revision control because it is not their input.
> And if they do exclude the files then their users are forced to
> generate the firmware. Excluding the aic7xxx generated files from
> source revision works for you because you always generate the firmware,
> it does not work for anybody else.
>
> >For those
> >that decide to keep the generated files in revision control, they
> >should pull any update to the generated files from the vendor (they
> >are always provided in my patches) and *never check the box*.
>
> Users must not be forced to go hunting for files from a vendor when the
> rst of the code is in the kernel. Especially when that vendor is not
> listed in MAINTAINERS and there is no contact data in the aic7xxx
> directory.
>
> >>The patch below fixes all of the above issues. It does not touch the
> >>aic7xxx code nor sequencer input, just the generated files and the
> >>kbuild related files. The patch is approx 100Kb but most of it is the
> >>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
> >
> >I don't see this as an improvement.
Re: Linux 2.4.5-ac17
On Fri, 22 Jun 2001, Tom Vier wrote: > On Fri, Jun 22, 2001 at 09:06:42AM +0200, Mike Galbraith wrote: > > It's not actually swapping unless you see IO (si/so). It's allocating > > swap space, but won't send pages out to disk unless there's demand. One > > if it's pre-allocation, why does it show up as "used"? "reserved" would be a > better fit. (Marcelo answered) > > benefit of this early allocation is that idle pages will be identified > > prior to demand, and will be moved out of the way sooner. Watch as > > how long can swap allocation possibly take? certainly no where near as long > as a write to disk takes. my box has a half gig of ram, pre-allocation is a > waste of cpu. i never hit swap. It's not that allocation takes long, it's the fact that no private pages were previously _in_ the aging pool. You see the pages which were added to the active page list for aging. Pages are aged down, and put on the inactive_dirty list. If demand exists, they are moved to the clean list and eventually reclaimed. If the page is touched at any time prior to being reclaimed, it stays is ram and is reactivated. Those which stay inactive are very good candidates for reclamation. You say pre-allocation is a waste of cpu.. how much cpu can you waste if you repeatedly eat and replentish your public cached data before you even think of shrinking netscape? How expensive can it be to have multiple tasks waiting for a page to be read from disk vs one task waiting for a private page? So you never hit swap, so what, your swap isn't hitting disk. If you have enough ram that you know for a fact that your cache won't be mangled by rss bloat, turn swap off. If that's the case, in fact you have too much ram :) For those where page replacement is a probability and for those who actually use the ram they have, aging private pages also vs only aging public pages until _crunch_ time makes good sense. -Mike - 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/
[OT]Re: One more ZDNet article with BillG hammering Linux and OpenSource.
On Fri, 22 Jun 2001, Ben Ford wrote: > Miles Lane wrote: > > >http://www.zdnet.com/zdnn/stories/news/0,4586,2777283,00.html > > > [ . . . ] > > > > >BillG -- We keep making it easier and easier, and anything people want source > >code for, we'll figure out a way to get it to them. It's kind of a strange > >thing in a way because most commercial customers don't want to recompile > >kernels or things like that. But they want to be able to know that things can > >be supported. > > > >We have some very cool tools now where we don't have to ship you the source. > >You can debug online, through the Internet. So it means you don't have to get > >a bunch of CDs. If you really want it for debugging and patching things, we > >can do that through the Internet. That's a real breakthrough in terms of > >simple source access. I don't know that anyone has ever asked for the source > >code for Word. If they did, we would give it to them. But it's not a typical > >request. > >- > > > > Hey, Bill, here's my address, can you ship me the full source to Word? Funny but by giving it to you they could really screw you when it comes to opensource work. If you think the GPL is viral you havn't seen "shared source".. at least the GPL only applies to derived works. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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 the VM motivations??
On Thu, 21 Jun 2001, Jason McMullan wrote: > > > I've been reading the VM thread off-and-on for, oh, the last > 8 _years_ on linux-kernel. It doesn't seem that much progress gets > made in any one direction. For every throughput optimination for servers, > the desktop people yell 'interactivity'. For every 'long-disk-idle' > desire the laptop guys have, others want large buffer caches. > > It goes back and forth. Everybody pulling from all sides, and > the VM performance has stayed (mostly) in the center. > > Well, I have an idea. Let's take a page from the Neural > Network guys (not the code, just the ideas), and look at VM from a > motivational perspective. > > What if the VM were your little Tuxigachi. A little critter > that lived in your computer, handling all the memory, swap, and > cache management. What would be the positive and negative feedback > you'd give him to tell him how well he's doing VM? > > Here's a short, off-the-cuff list that hopefully most > everyone can agree on. > > Positive > > * Low system CPU load for the VM timeslice > * Process IO requests / Disk IO is less than 1.0 > * Large idle times between disk activity > * Process don't have to wait long for pages from VM. > * etc. > > Negative > > * High CPU usage for VM > * High disk IO for low number of process IO requests. > * Disk is rarely idle > * Processes stall for a long time waiting for VM. > * Deadlocks (fatal!) > * etc. > > One we know how we would 'train' our little VM critter, we > will know how to measure its performance. Once we have measures, we > can have good benchmarks. Once we have good benchmarks - we can pick > a good VM alg. We are talking with the OSDL people (http://www.osdlab.org) to setup an automatic testing system (differents benchmarks, different configurations, etc) which will give us a wider notion of VM changes wrt performance. - 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: One more ZDNet article with BillG hammering Linux and Open Source.
Miles Lane wrote: >http://www.zdnet.com/zdnn/stories/news/0,4586,2777283,00.html > [ . . . ] > >BillG -- We keep making it easier and easier, and anything people want source >code for, we'll figure out a way to get it to them. It's kind of a strange >thing in a way because most commercial customers don't want to recompile >kernels or things like that. But they want to be able to know that things can >be supported. > >We have some very cool tools now where we don't have to ship you the source. >You can debug online, through the Internet. So it means you don't have to get >a bunch of CDs. If you really want it for debugging and patching things, we >can do that through the Internet. That's a real breakthrough in terms of >simple source access. I don't know that anyone has ever asked for the source >code for Word. If they did, we would give it to them. But it's not a typical >request. >- > Hey, Bill, here's my address, can you ship me the full source to Word? ;) -- :__o : -\<, : 0/ 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/
Annoying kernel behaviour
I upgraded a fileserver to 2.4.5 because of the RAID support (the 0.90 patch I grabbed did not apply cleanly to 2.2.19, despite it being a fresh copy). Besides a nice speed increase (the EEPro now pumps 10 megs a second, instead of 2 or 3), there is a problem with the video4linux in it. The box has a bttv card hooked up to a camera. Under 2.2.19, Apache had mod_video installed, which would produce a jpeg of the composite in on the card (a cheapy CCD camera is hooked up). Upon insmoding: Module Size Used by bttv 55184 0 (unused) videodev4864 2 [bttv] i2c-algo-bit7712 1 [bttv] i2c-dev 3904 0 (unused) i2c-core 12656 0 [bttv i2c-algo-bit i2c-dev] and accesing mod_video, the box locked up hard (not even sysrq worked). And when I rebooted, I found that some files is /etc were eaten -- even though that partition is mounted with the sync option, and even though it'd had a good 2-5 seconds the write the ~10k data file. So why does bttv lock the box, and why does sync not sync? I don't feel like converting ~80gb to some other FS than ext2 just yet. PS: I can't give an Oops because the DPMS mode on the console was on, and it won't return when it locks up (perhaps turn on monitor as part of Oops handling?). Assuming there even was an oops. PPS: Please CC me since I'm not on the list. -- www.kuro5hin.org -- technology and culture, from the trenches. - 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/
Compaq launches Open SSI Cluster Projects
Compaq has launched two open source technology projects under the GPL license. They are briefly described below and can be found through www.opensource.compaq.com. We are actively looking for technology partners, contributors, consultants and general kibitzers to participate via the email lists set up for each project. Those that just want to monitor the projects are welcome as well. Cluster Infrastructure for Linux (CI) The goal of this project is to develop a common infrastructure for many if not all forms of Linux clustering by extending the Cluster Membership and Inter-node Communication Subsystems from Compaq's NonStop Clusters for Unixware code base. This project also provides the basis for the Open SSI Clusters for Linux project. A developers download is available via www.opensource.compaq.com for Intel-32, along with build, boot, hook, interface and api documentation. We will put the CVS repository on the web when we can. A port to the alpha chip has already succeeded and patches for that are available. Open Single System Image (SSI) Clusters for Linux Project The Open SSI project leverages both Compaq's NonStop Clusters for Unixware technology and other open source technology to provide a full, highly available SSI environment for Linux. Goals for SSI Clusters include availability, scalability and manageability, built from standard servers. Technology pieces will include: membership, single root and single init, cluster filesystems and DLM, single process space and process migration, load leveling, availability monitors and failover, single namespace and shared access for all forms of IPC, devices and networking, and a single management space. The SSI project will leverage the Cluster Infrastructure for Linux project. Source beyond the CI base is not yet available. We are aiming for a developers release of much of functionality in July. In the meantime there is a presentation on SSI Clustering on the web. An initial list of component requirements will soon be posted for discussion and refinement. Join the mail alias via www.opensource.compaq.com to stay updated. bruce walker SSI Cluster Architect Linux Program Office Compaq Computers - 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: problem with select() - 2.4.5
Thomas Speck wrote: > > tio.c_cflag = baud | CLOCAL; How about adding CREAD? Ciao, ET. - 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: bugreport: poll() timeout always takes 10ms too long
Tachino Nobuhiro wrote: > > Hello, > > At Fri, 22 Jun 2001 11:52:12 +1000, > [EMAIL PROTECTED] wrote: > > > > [1.] One line summary of the problem: > > > > poll() timeout always takes 10ms too long > > > > [2.] Full description of the problem/report: > > > > Select() timeouts work fine. A timeout between 10n-9 and 10n ms times > > out after 10n ms on average. Poll() timeouts between 10n-9 and 10n ms, > > on the other hand, time out after 10(n+1) ms on average. It's always a > > jiffy too long. This means it's impossible to set a 10ms timeout using > > poll() even though it's possible using select(). The programs and their > > output below [6] demonstrate this. The same behavious occurs with > > linux-2.2 and linux-2.4. > > > I think this is correct behavior. The Single UNIX Specification > describes about the timeout parameter of poll() as follows, > > If none of the defined events have occurred on any selected > file descriptor, poll() waits at least timeout milliseconds > for an event to occur on any of the selected file descriptors. > > On the other hand, select(), > > If the specified condition is false for all of the specified > file descriptors, select() blocks, up to the specified timeout > interval, until the specified condition is true for at least > one of the specified file descriptors. ok, it's a correct behaviour. but having both poll and select timeout at the time specified would also be correct behaviour. better than that, it would be expected behaviour. raf - 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: ACPI + Promise IDE = disk corruption :-(((
> From: Alan Cox [mailto:[EMAIL PROTECTED]] > I've seen several people report ACPI eats disks. ACPI is > incredibly complex > badly designed crud. My advice is never use ACPI. This > incidentally appears > to be the advice Microsoft give people too - they tell people > to disable > ACPI as one of the first steps to diagnosing strange crashes > in machines They're just bugs. That's why it's marked experimental, and unlike the rest of the "experimental" drivers, we aren't kidding. It's just *one* issue that has generated all the disk corruption reports. Putting the processor into the C3 power state, in combination with bus mastering. This is disabled in the most recent release. I'd love to fix this one, but if it were easy, it'd be fixed by now. Maybe you can shed some light - if you're willing, let me know and I'll describe the problem in greater detail. > I've been discussing with a few folk about doing an > alternative mini acpi > subset so that Linux can be booted on most 'ACPI only' > hardware without > using all the ACPI junk Could these discussions be opened up to a wider readership? Perhaps you could use [EMAIL PROTECTED], or [EMAIL PROTECTED]? Regards -- Andy - 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] fix RLIMIT_NPROC accounting
Hi, due to something which I consider to be a kernel bug it's impossible for pam to do its job and set the per-user RLIMIT_NPROC (number of processes limit) to something which is lower than the amount of processes root is running at that moment. At least, it fails with all programs which set RLIMIT_NPROC and fork()+exec() afterwards. The attached patch should bring us back to the behaviour we had in 2.2. Comments? regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ --- kernel/fork.c.orig Fri Jun 22 20:27:27 2001 +++ kernel/fork.c Fri Jun 22 20:52:41 2001 @@ -576,7 +576,14 @@ *p = *current; retval = -EAGAIN; - if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) + /* +* Check if we are over our maximum process limit, but be sure to +* exclude root. This is needed to make it possible for login and +* friends to set the per-user process limit to something lower +* than the amount of processes root is running. -- Rik +*/ + if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur + && !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE)) goto bad_fork_free; atomic_inc(>user->__count); atomic_inc(>user->processes); - 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.5]Patch - fix page leak in nfs_prepare_write()
Hi,
The following patch fixes a leak in high memory in case a
process is signalled while in nfs_prepare_write().
Cheers,
Trond
diff -u --recursive --new-file linux-2.4.6-mmap/fs/nfs/file.c
linux-2.4.6-file/fs/nfs/file.c
--- linux-2.4.6-mmap/fs/nfs/file.c Tue May 22 18:26:06 2001
+++ linux-2.4.6-file/fs/nfs/file.c Fri Jun 22 18:43:34 2001
@@ -162,9 +162,18 @@
*/
static int nfs_prepare_write(struct file *file, struct page *page, unsigned offset,
unsigned to)
{
+ int status;
+
kmap(page);
- return nfs_flush_incompatible(file, page);
+ status = nfs_flush_incompatible(file, page);
+ if (status)
+ goto out_err;
+ return 0;
+ out_err:
+ kunmap(page);
+ return status;
}
+
static int nfs_commit_write(struct file *file, struct page *page, unsigned offset,
unsigned to)
{
long status;
-
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.5-ac17
On Fri, 22 Jun 2001, Tom Vier wrote: > On Fri, Jun 22, 2001 at 09:06:42AM +0200, Mike Galbraith wrote: > > It's not actually swapping unless you see IO (si/so). It's allocating > > swap space, but won't send pages out to disk unless there's demand. One > > if it's pre-allocation, why does it show up as "used"? > "reserved" would be a better fit. You're right. Its just that nobody fixed the code yet. - 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: [RFC] Early flush (was: spindown)
On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:
> Daniel Phillips writes:
> > I'd like that too, but what about sync writes? As things stand now,
> > there is no option but to spin the disk back up. To get around this
> > we'd have to change the basic behavior of the block device and
> > that's doable, but it's an entirely different proposition than the
> > little patch above.
>
> I don't care as much about sync writes. They don't seem to happen very
> often on my boxes.
syslog and some editors are the most common users of sync writes. vim, e.g.,
per default keeps fsync()ing its swapfile. Tweaking the configuration of
these apps, this can be prevented fairly easy though. Changing sync semantics
for this matter on the other hand seems pretty awkward to me. I'd expect an
application calling fsync() to have good reason for having its data flushed
to disk _now_, no matter what state the disk happens to be in. If it hasn't,
fix the app, not the kernel.
> > You know about this project no doubt:
> >
> >http://noflushd.sourceforge.net/
>
> Only vaguely. It's huge. Over 2300 lines of C code and >560 lines in
> .h files! As you say, not really lightweight. There must be a better
> way.
noflushd would benefit a lot from being able to set bdflush parameters per
device or per disk. So I'm really eager to see what Daniel comes up with.
Currently, we can only turn kupdate either on or off as a whole, which means
that noflushd implements a crude replacement for the benefit of multi-disk
setups. A lot of the cruft stems from there.
> Also, I suspect (without having looked at the code) that it
> doesn't handle memory pressure well. Things may get nasty when we run
> low on free pages.
It doesn't handle memory pressure at all. It doesn't have to. noflushd only
messes with kupdate{,d} but leaves bdflush (formerly known as kflushd) alone.
If memory gets tight, bdflush starts writing out dirty buffers, which makes the
disk spin up, and we're back to normal.
Regards,
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: spindown
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote: > Pavel Machek wrote: > > > Isn't this why noflushd exists or is this an evil thing that shouldn't > > > ever be used and will eventually eat my disks for breakfast? > > > > It would eat your flash for breakfast. You know, flash memories have > > no spinning parts, so there's nothing to spin down. > > Btw Pavel, does noflushd work with 2.4.4? The noflushd version 2.4 I > tried said it couldn't find some kernel process (kflushd? I don't > remember) and that I should use bdflush. The manual says that's > appropriate for older kernels, but not 2.4.4 surely. That's because of my favourite change from the 2.4.3 patch: - strcpy(tsk->comm, "kupdate"); + strcpy(tsk->comm, "kupdated"); noflushd 2.4 fixed this issue in the daemon itself, but I had forgotten about the generic startup skript. (Rpms and debs run their customized versions.) Either the current version from CVS, or ed /your/init.d/location/noflushd << EOF %s/kupdate/kupdated/g w q EOF should get you going. Regards, 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.2 yenta_socket problems on ThinkPad 240
You should try 2.4.6-pre5, it already includes a patch for you :) pci=assign-busses on the command line. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - 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.2 yenta_socket problems on ThinkPad 240
I wrote:
> Does it make sense to turn pcibios_assign_all_busses into a variable
> with a default value of zero, and implement a kernel argument to set it?
After some discussion of various alternatives, including always turning it
on (bad for some systems), or writing a function to try to determine if
the configuration left by the BIOS is sane (maybe OK, but could still need
to be overridden), Linus wrote:
> Regardless, it would certainly make sense to have a manual override, with
> a kernel command line. If for no other reason than to allow for mistakes
> and let the user force the old/new behaviour.
Since I offered to generate a suitable patch, below find one against
2.4.5. This patch ONLY tries to provide for the command line override.
I had to touch more files than I would have liked, and unfortunately can
only test it on x86 even though it potentially affects other
architectures. It seems to do the right thing on my IBM ThinkPad 240.
What I've done is:
1) Replaced the pcibios_assign_all_busses() macro in each architecture
with a defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT. Note that some
architectures were using a function instead of a macro, but the function
just returned the contents of a variable.
2) Added the variable pci_assign_all_busses, which gets initialized from
the defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT.
3) Added a __setup macro and function to handle a command line argument
"pci_assign_all_busses=1" (or zero), which sets the pci_assign_all_busses
variable.
4) Changed the code in drivers/pci/pci.c to use the variable rather than
the old macro/function.
If code is added to attempt to automatically determine whether bus
configuration is needed, and if that code runs after the command line is
parsed, it might be necessary to add a second variable (or special
values of the existing one) to avoid changing the variable if the user
has specified a value on the command line, since the whole point is to
allow the user to override the default behavior.
If I've done this in a suboptimal manner, I'd be happy to hear
suggestions of better approaches. As submitting kernel patches goes,
this is my first time, so please be gentle. :-)
Thanks,
Eric
diff -uNr linux-2.4.5.orig/arch/parisc/kernel/inventory.c
linux-2.4.5/arch/parisc/kernel/inventory.c
--- linux-2.4.5.orig/arch/parisc/kernel/inventory.c Wed Dec 6 11:46:39 2000
+++ linux-2.4.5/arch/parisc/kernel/inventory.c Thu Jun 21 18:26:52 2001
@@ -138,6 +138,7 @@
ulong pcell_loc;
pdc_pat = (pdc_pat_cell_get_number(_result) == PDC_OK);
+ pci_assign_all_busses = pdc_pat;
if (!pdc_pat)
{
return 0;
diff -uNr linux-2.4.5.orig/arch/ppc/kernel/pci.c linux-2.4.5/arch/ppc/kernel/pci.c
--- linux-2.4.5.orig/arch/ppc/kernel/pci.c Mon May 21 17:04:47 2001
+++ linux-2.4.5/arch/ppc/kernel/pci.c Thu Jun 21 18:26:52 2001
@@ -47,10 +47,6 @@
static void pcibios_fixup_cardbus(struct pci_dev* dev);
#endif
-/* By default, we don't re-assign bus numbers. We do this only on
- * some pmacs
- */
-int pci_assign_all_busses;
struct pci_controller* hose_head;
struct pci_controller** hose_tail = _head;
@@ -752,11 +748,6 @@
ppc_md.pcibios_after_init();
}
-int __init
-pcibios_assign_all_busses(void)
-{
- return pci_assign_all_busses;
-}
void __init
pcibios_fixup_pbus_ranges(struct pci_bus * bus, struct pbus_set_ranges_data * ranges)
diff -uNr linux-2.4.5.orig/drivers/pci/pci.c linux-2.4.5/drivers/pci/pci.c
--- linux-2.4.5.orig/drivers/pci/pci.c Sat May 19 17:43:06 2001
+++ linux-2.4.5/drivers/pci/pci.c Thu Jun 21 18:26:52 2001
@@ -37,6 +37,19 @@
LIST_HEAD(pci_root_buses);
LIST_HEAD(pci_devices);
+
+int pci_assign_all_busses = PCI_ASSIGN_ALL_BUSSES_DEFAULT;
+
+
+static int __init pci_assign_all_busses_setup(char *str)
+{
+ pci_assign_all_busses = simple_strtol(str,NULL,0);
+ return 1;
+}
+
+__setup("pci_assign_all_busses=", pci_assign_all_busses_setup);
+
+
/**
* pci_find_slot - locate PCI device from a given PCI slot
* @bus: number of PCI bus on which desired PCI device resides
@@ -957,7 +970,7 @@
pci_read_config_dword(dev, PCI_PRIMARY_BUS, );
DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n", dev->slot_name,
buses & 0xff, pass);
- if ((buses & 0x00) && !pcibios_assign_all_busses()) {
+ if ((buses & 0x00) && !pci_assign_all_busses) {
/*
* Bus already configured by firmware, process it in the first
* pass and just note the configuration.
diff -uNr linux-2.4.5.orig/include/asm-alpha/pci.h linux-2.4.5/include/asm-alpha/pci.h
--- linux-2.4.5.orig/include/asm-alpha/pci.hMon May 21 13:38:41 2001
+++ linux-2.4.5/include/asm-alpha/pci.h Thu Jun 21 18:26:52 2001
@@ -46,7 +46,7 @@
/* Override the logic in pci_scan_bus for skipping already-configured
bus numbers. */
-#define
Re: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
Johannes Erdfelt wrote: > > I think this may be a problem in the dc2xx.o then, since uhci didn't reveal > > any new messages. > > It's possible. Many cameras are touchy wrt to the commands it receives. > If one is slightly wrong, some of them will just stop talking. Yeah, looks like I get to see if I can debug the camera driver.. > Did you try with the usb-uhci driver as well? > > JE Here's a transcript of a session with usb-uhci.o (vs uhci.o). It locks in a way that I can't turn off the camera (have to pop batteries), which is a bit worse than just uhci.o. On the plus side, it seemed a bit faster at a few things. usb.c: USB disconnect on device 1 usb.c: USB bus 1 deregistered usb.c: USB disconnect on device 1 usb.c: USB bus 2 deregistered usb-uhci.c: $Revision: 1.259 $ time 16:56:57 Jun 22 2001 usb-uhci.c: High bandwidth mode enabled PCI: Found IRQ 5 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 5 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 usb-uhci.c: USB UHCI at I/O 0xd000, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber usb-uhci.c: USB Universal Host Controller Interface driver hub.c: USB new device connect on bus1/2, assigned device number 2 dc2xx.c: USB Camera #0 connected, major/minor 180/80 usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb-uhci.c: interrupt, status 3, frame# 1004 usb.c: USB disconnect on device 2 usb-uhci.c: interrupt, status 3, frame# 1997 usb-uhci.c: interrupt, status 3, frame# 949 usb-uhci.c: interrupt, status 3, frame# 1949 usb-uhci.c: interrupt, status 3, frame# 901 usb-uhci.c: interrupt, status 3, frame# 1901 dc2xx.c: USB Camera #0 disconnected -- www.kuro5hin.org -- technology and culture, from the trenches. - 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.5-ac17 oops on Sony Vaio pCG-FX140
Hi Alan, ac17 oopsed on boot, ac16 runs fine. Here is the output of lspci -v and ksymoops. I hope I did not make too many typos when I copied the oops. Regards, Petr lspci -v output: 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 11) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, fast devsel, latency 0 Capabilities: [88] #09 [f205] 00:02.0 VGA compatible controller: Intel Corporation: Unknown device 1132 (rev 11) (prog-if 00 [VGA]) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10 Memory at f800 (32-bit, prefetchable) [size=64M] Memory at f400 (32-bit, non-prefetchable) [size=512K] Capabilities: [dc] Power Management version 2 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: f410-f41f 00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 03) (prog-if 80 [Master]) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, medium devsel, latency 0 I/O ports at 1800 [size=16] 00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03) (prog-if 00 [UHCI]) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1820 [size=32] 00:1f.3 SMBus: Intel Corporation 82820 820 (Camino 2) Chipset SMBus (rev 03) Subsystem: Sony Corporation: Unknown device 80df Flags: medium devsel, IRQ 5 I/O ports at 1810 [size=16] 00:1f.4 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub B) (rev 03) (prog-if 00 [UHCI]) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 2400 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device 2445 (rev 03) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 1c00 [size=256] I/O ports at 1840 [size=64] 00:1f.6 Modem: Intel Corporation: Unknown device 2446 (rev 03) (prog-if 00 [Generic]) Subsystem: Sony Corporation: Unknown device 80df Flags: medium devsel, IRQ 5 I/O ports at 2000 [size=256] I/O ports at 1880 [size=128] 01:00.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8021 (rev 02) (prog-if 10 [OHCI]) Subsystem: Sony Corporation: Unknown device 80df Flags: medium devsel Memory at f4104000 (32-bit, non-prefetchable) [disabled] [size=2K] Memory at f410 (32-bit, non-prefetchable) [disabled] [size=16K] Capabilities: [44] Power Management version 2 01:02.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, medium devsel, latency 0 Memory at f4106000 (32-bit, non-prefetchable) [size=4K] Bus: primary=01, secondary=02, subordinate=05, sec-latency=0 I/O window 0: -0003 I/O window 1: -0003 16-bit legacy interface ports at 0001 01:02.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Subsystem: Sony Corporation: Unknown device 80df Flags: bus master, medium devsel, latency 0 Memory at f4107000 (32-bit, non-prefetchable) [size=4K] Bus: primary=01, secondary=06, subordinate=09, sec-latency=0 I/O window 0: -0003 I/O window 1: -0003 16-bit legacy interface ports at 0001 01:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2) Chipset Ethernet (rev 03) Subsystem: Intel Corporation: Unknown device 3013 Flags: bus master, medium devsel, latency 66, IRQ 9 Memory at f4105000 (32-bit, non-prefetchable) [size=4K] I/O ports at 3000 [size=64] Capabilities: [dc] Power Management version 2 ksymoops 2.4.1 on i686 2.4.5-ac16. Options used -V (specified) -K (specified) -L (specified) -o /lib/modules/2.4.5-ac17 (specified) -m /boot/System.map-2.4.5-ac17 (specified) No modules in ksyms, skipping objects Unable to handle kernel NULL pointer dereference at virtual address 0030 c019c23c *pde = Oops: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: ebx: 0286 ecx: c0267784 edx: c14f7fd3 esi: 0040edi:
signals and user mode interaction...
Hello Is there a method to stack signals? i.e when multiple signals are delivered to the process, instead of being 1 shot, that signals get delivered as many times? and from kernel mode, can we pass arguments in the signal handler? for eg: if i have SIGUSR1 for each signal delivered by the kernel, i would like to pass some special parameter to the signal handler.? ashokr -- Ashok Raj Phone: (503)-712-5966 Intel Enterprise Product Group - Fabric Components Division (FCD) Fax: (503)-712-1429 Mail Stop: JF5-361 5200, NE Elam Young Parkway Hillsboro, OR - 97124 - 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: EEPRO100/S support
>The e100 driver from intel claims to support these cards (the 100 S >desktop adaptor, that is), but in fact the drivers lock up under heavy >UDP load (at least they do for me in 2.2.19). It seems to only be a >problem with these newer cards, the e100 is solid with older cards >(and things like the 100VE which is onboard on many Easterns). > >Intel are working on fixing the lockups, they thought it was related >to the checksum offload though turning that off doesn't prevent the >lockups. Version 1.66 is much more stable than 1.55a (1.55a would >lockup after 60-80M of traffic on these cards), I'm awaiting the next >version to see if they have nailed it. > A temporary workaround for e100-1.6.6 that works in most cases is to disable the CPUSaver features by using the ucode=0 option. > >I've no idea if the e100 works on anything other than ia32/ia64. Yes it does. At this point it should be platform independent, I see all the required changes for both big and little endian support. ~joe smime.p7s
Microsoft and Xenix.
I am not subscribed to the list, but I scan the archives and saw the following. Please cc e-mail me in followups. >Rob Landley ([EMAIL PROTECTED]) wrote ... >In late '79 early '80, they heard the rumors that IBM was pondering a PC, > and Paul Allen went "any real computer will run Unix", so they got a >license from AT and ported the sucker, calling it "Xenix". (MS was a >porting house, I hope the following adds a more direct perspective on this, as I was a user at the time. I was working (and still am) for a UK computer systems integrator called Logica. One of our departments sold and supported Xenix (as distributor for Microsoft? - all the manuals had Logica on the covers although there was at least some mention of Microsoft inside) in the UK. At the time it ONLY ran on PDP 11's and I used it to build a configuration management system (on top of SCCS) for the telemetry product that I was responsible for. I acquired Xenix for my department in 1984 It was more like (can't remember exactly when) 1985/1986 that Xenix got ported to the IBM PC. I remember because we were evaluating software to use for our telemetry workstations (which previously had been using expensive special graphics hardware and we were trying to see if we could use a PC instead) and I was comparing Xenix, GEM (remember that - for a time it looked like it might be ahead of windows) and Microsoft Windows v 1 . We chose Windows in the end for its graphics capability although by the time we started development it was up to v2 and we were using 286's (this was 1987/88). ... >Xenix was unloaded on the Santa-Cruz operation almost >immediately, Logica sold out its Xenix operation to Santa-Cruz around 1987 (definately before October 1987) because we couldn't afford the costs of developing the product (which makes me think that we had bought it out from Microsoft - at least in the UK). By then we had switched our PDP 11s to System V (I also remember BUYING an editor called "emacs" for use on it:-) ). -- Alan - [EMAIL PROTECTED] http://www.chandlerfamily.org.uk - 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.5-ac17
On Fri, Jun 22, 2001 at 09:06:42AM +0200, Mike Galbraith wrote: > It's not actually swapping unless you see IO (si/so). It's allocating > swap space, but won't send pages out to disk unless there's demand. One if it's pre-allocation, why does it show up as "used"? "reserved" would be a better fit. > benefit of this early allocation is that idle pages will be identified > prior to demand, and will be moved out of the way sooner. Watch as how long can swap allocation possibly take? certainly no where near as long as a write to disk takes. my box has a half gig of ram, pre-allocation is a waste of cpu. i never hit swap. > memory demand rises, and you should see these pages migrating to disk > and staying there.. buys you more working space. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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/
High system CPU% in dual CPU System
I'm experiencing very high system CPU% indications on my new dual Pentium III machine (SuSE Linux 7.1, Kernel 2.4.4-SMP): 12:26am up 1 day, 8:34, 9 users, load average: 1.44, 2.74, 3.26 116 processes: 113 sleeping, 3 running, 0 zombie, 0 stopped CPU0 states: 19.2% user, 32.0% system, 0.0% nice, 48.2% idle CPU1 states: 20.4% user, 40.1% system, 0.0% nice, 38.3% idle Mem: 512180K av, 498144K used, 14036K free, 0K shrd, 145360K buff Swap: 1024120K av,8504K used, 1015616K free 39976K cache PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 20308 root 9 0 21056 20M 1744 S 2.7 4.1 6:14 X 30471 capicall 12 0 1020 1020 772 R 0.7 0.1 0:36 top 594 root 9 0 628 628 480 S 0.5 0.1 6:59 nscd 22072 ingo 17 0 1484 1484 576 R 0.5 0.2 0:00 ps 596 root 9 0 628 628 480 S 0.3 0.1 6:36 nscd 22467 ingo 9 0 3940 3940 2812 R 0.3 0.7 11:03 gkrellm 22978 ingo 9 0 1380 1380 1132 S 0.3 0.2 0:04 ssh 597 root 9 0 628 628 480 S 0.1 0.1 6:31 nscd 598 root 9 0 628 628 480 S 0.1 0.1 6:35 nscd 22071 ingo 17 0 1036 1036 852 S 0.1 0.2 0:00 sh ... After the initial Installation everything was fine - it must be caused by some additonal package, but I have no clue. What can I do to find out what the CPUs are doing during "system" time? -- Ingo [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: ACPI + Promise IDE = disk corruption :-(((
> I enabled ACPI in 2.4.5-ac17 (2.4.5-ac16 works fine with the same config > except ACPI). When I booted I saw a message > I hit reset hoping to boot the system with "acpi=no-idle", but GRUB > couldn't load stage2, which resides on the root partition (reiserfs). I've seen several people report ACPI eats disks. ACPI is incredibly complex badly designed crud. My advice is never use ACPI. This incidentally appears to be the advice Microsoft give people too - they tell people to disable ACPI as one of the first steps to diagnosing strange crashes in machines ACPI is over complex, new technology. The BIOS stuff is new (and frequently wrong), the kernel stuff is new (and has plenty of known bugs) and the combination is a recipe for disaster. I've been discussing with a few folk about doing an alternative mini acpi subset so that Linux can be booted on most 'ACPI only' hardware without using all the ACPI junk 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: For comment: draft BIOS use document for the kernel
> lilo > grub > syslinux > XFree86 (using virtual-8088 to run a video BIOS for a second card?) Also for monitor identification > dosemu? > loadlin? loadlin does. Dosemu can. It depends how it is configured The Red Hat installer uses LRMI to do monitor identification by BIOS calls too. I've not tried to document these users. > the boot block that reads ext2 (in 1 kB -- damn what a hack) The Linux8086 minixfs booter is an even better hack - its in C. - 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: /dev/nvram driver
> Currently it tracks O_EXCL on open() and sets a flag, whereby no other > open() calls can succeed. Is this functionality really needed? Perhaps it > should just be a reader/writer model : n readers or 1 writer. In that > case, should open() block on a writer, or return -EBUSY? Several tools expect that mode of behaviour so that they can atomically recompute the checksum when writing low bytes of the CMOS - 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: For comment: draft BIOS use document for the kernel
> It's in arch/i386/boot/setup.S, after label bootsect_second. It's only > used with bzImage kernels and the floppy bootsector. I stand corrected. I will add this to the documentation 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/
[PATCH] CREDITS update
Hi, seems that I've forgotten to update my CREDITS entry for quite a long time now. Patch attached ;) Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ --- CREDITS.origFri Jun 22 18:41:15 2001 +++ CREDITS Fri Jun 22 18:42:06 2001 @@ -2337,14 +2337,15 @@ S: France N: Rik van Riel -E: [EMAIL PROTECTED] -W: http://www.nl.linux.org/~riel/ +E: [EMAIL PROTECTED] +W: http://www.surriel.com/ D: Linux-MM site, Documentation/sysctl/*, swap/mm readaround D: clustering contributor, kswapd fixes, random kernel hacker, -D: nl.linux.org maintainer, minor scheduler additions -S: IJsselstraat 23a -S: 9725 GA Groningen -S: The Netherlands +D: nl.linux.org administrator, minor scheduler additions +S: Conectiva S.A. +S: R. Tocantins, 89 - Cristo Rei +S: 80050-430 - Curitiba - Paraná +S: Brazil N: Pekka Riikonen E: [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: For comment: draft BIOS use document for the kernel
> Then how does 1.44 megabytes of data from a floppy disk (that won't > fit below 1 megabyte), that is accessed in real-mode, ever get to > above 1 megabyte where it can be decompressed? The limit is about 508K of compressed image with the floppy boot. > I think LILO copies each buffer read from a below 1 Megabyte buffer > (which is the only place the floppy can put its data via the BIOS), > to above 1 megabyte using the BIOS block-move function. I can't speak for LILO. I've not tried to document LILO, rather I've tried to document the kernel. Possibly someone should add LILO documentation to this. 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/
How does ramfs actually fills the page cache with data?
In fs/ramfs/inode.c, how does ramfs actually fills the page cache with data? In the readpage operation, it only zero-fill the page if it didn't already exist in the page cache. However, how do I actually fill the page with data? Thanks a lot. __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - 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: Is this part of newer filesystem hierarchy?
Again i am confused.
/usr/bin/ld is linker at compilation time, at it works how i told in
second part
of my mail, (just try to compile it, it comes with binutils,
ftp.kernel.org/pub/linux/devel/binutils).
/lib/d-2.2.X.so is what you are talking about.
So should i think os an hack to ld-2.2.3.so ??
to see how it works loock at /usr/bin/ldd, it's an interesting script.
I can understand why old glibc 2.1 is not isered in the directories
where ldconfig has to loock to create its db for loader, but there should
be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
subdirectories)
for glibc 2.2, since it is necessary at compilation
time.
This do not change the problem which is related to /lib/ld-2.2.X.so.
doing a strings /lib/ld-2.XXX
you will find also
info[19]->d_un.d_val == sizeof (Elf32_Rel)
info[20]->d_un.d_val == 17
/lib/
/usr/lib/
{ORIGIN}
{PLATFORM}
expand_dynamic_string_token
dl-load.c
this is the interesting section of the output. This way you can check for
an hack to the loader, but I think to something else instead of an hack.
I do not have a red hat here around, since i do prefer another style for
my linux systems, so i cannot check by person.
Luigi Genoni
On Fri, 22 Jun 2001, D. Stimits wrote:
> Luigi Genoni wrote:
> >
> > I do not know if this is a new filesystem hierarchy, it should not be,
> > at less untill lsb finishes all discussion (anyway it is similar to lsb
> > standard). Your mail is a little confusing for me. Let's see if i can
> > clarify my ideas.
> >
> > On Thu, 21 Jun 2001, D. Stimits wrote:
> >
> > > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > > differently than just /lib/. Here is the structure I found:
> > >
> > > /lib/ has:
> > > libc-2.2.2.so (hard link)
> > > libc.so.6 (sym link to above)
> > >
> > > A new directory appears, /lib/i686/ (uname -m is i686):
> > > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > > libc.so.6 (sym link to hard link in this directory)
> > >
> > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > > while the 1.2 MB version is stripped.
> > >
> > > Here is the peculiar part that I need to find out about. My
> > > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > > the i686 directory is being checked if it is not listed in ld.so.conf
> > > and not part of any LD path variable? I am using a non-Redhat kernel
> > > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > > kernel itself. My ld version:
> > excuse, but if you do something like,
> > ldd /bin/ls
> >
> > what do you get, which libc is loaded?
>
> :~# ldd /bin/ls
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
> libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
>
> The i686 subdirectory version is visible to the linker. I don't know
> how.
>
> >
> > have you got a file like /etc/ld.so.preload??
>
> No. Nor are any preload or LD environment variables set. Something
> Redhat has done is making the i686 subdirectory visible. Maybe ld
> searches recursively?
>
> > basically you can use the stripped glibc (faster), but then,
> > if you have troubles and you need to debug, just set the preload file,
> > or use LD_PRELOAD variable to use
> > the non stripped library. In princip it is not a stupid idea,
> > not that i like it, but it is not stupid.
>
> Without any preload, it appears the linker is by default choosing the
> debug version in the i686 subdirectory. Redhat must have mucked with it,
> otherwise I don't see how it could be searching the i686 subdirectory
> without any configuration customization (no preload, no LD environment
> variables). But this is what I want to verify...where the "mucking" has
> occurred, it is important to find out for some software that is used to
> create custom and/or rescue disks. (alternately, to find out if there is
> a predictable scheme, such as knowning ld is searching recursively, or
> searches for /lib/{uname -m})
>
> >
> > > ~# ld --version
> > > GNU ld 2.10.91
> > > Copyright 2001 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms
> > > of
> > > the GNU General Public License. This program has absolutely no
> > > warranty.
> > > Supported emulations:
> > >elf_i386
> > >i386linux
> > >elf_i386_glibc21
> > >
> > > Possibly Redhat altered ld? According to the man page, this directory
> > > should not be found since it is not part of ld.so.conf, and also the
> > > /lib/ version *should* be found (but isn't). What has changed, is it a
> > > standard for filesystem hierarchy, or is
Re: Maintainers master list?
** Reply to message from "Eric S. Raymond" <[EMAIL PROTECTED]> on Fri, 22 Jun 2001 17:09:45 -0400 > What happens now when somebody takes over responsibility for a file > or subsystem and the MAINTAINERS file doesn't get patched, either because > that person forgets to send a MAINTAINERS update or Linus doesn't > happen to take the MAINTAINERS patch for a while? Wouldn't this whole problem go away if the kernel source were stored in a master CVS repository? Maintainers would have write access to their respective code, but only Linus and Alan would have delete access. Everyone else would have read-only access. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - 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: ACPI + Promise IDE = disk corruption :-(((
Just a note, in 2.4.6-pre5, the acpi=no-idle option goes away, but you should no longer experience any corruption issues, either. Regards -- Andy PS sorry you experienced problems - glad you could recover. > From: Pavel Roskin [mailto:[EMAIL PROTECTED]] > Hello! > > It's just a word of warning for those who are trying ACPI > with the latest > kernels. > > I enabled ACPI in 2.4.5-ac17 (2.4.5-ac16 works fine with the > same config > except ACPI). When I booted I saw a message > > ACPI: If experiencing system slowness, try adding "acpi=no-idle" to > cmdline > > and after that ... > > reiserfs: checking transaction log (device 21:04) ... > > Normally it takes few seconds before the system goes further, but that > time it tool much longer (one minute maybe), and the next message was > something like "hde: DMA timeout" > > I hit reset hoping to boot the system with "acpi=no-idle", but GRUB > couldn't load stage2, which resides on the root partition (reiserfs). > > I had to install Linux on another drive and run reiserfsck. > It found many > errors, fixed them all, and now I'm happily running my old system. > > I also checked the same kernel with "acpi=no-idle" - it > works. The ACPI > messages are now: > > ACPI: Core Subsystem version [20010208] > ACPI: Subsystem enabled > ACPI: System firmware supports: C2 C3 > ACPI: plvl2lat=10 plvl3lat=20 > ACPI: C2 enter=143 C2 exit=35 > ACPI: C3 enter=858 C3 exit=71 > ACPI: Not using ACPI idle > ACPI: System firmware supports: S0 S1 S5 > > The config file is here: http://www.red-bean.com/~proski/linux/config > dmesg output is here: http://www.red-bean.com/~proski/linux/dmesg > > Possibly important data: > > Kernel compiled with gcc-3.0 > Motherboard Micron SE440-BX2 > BIOS 4S4EB2X0.05A.0016.P15 (the latest) > 1 Intel Pentium III 550MHz > Root filesystem is reiserfs > Root filesystem is on Promise PDC20267 ide controller > Local APIC (but not IO-APIC) is used. > > I can make more experiments (with other hard drives) if needed. > > -- > Regards, > Pavel Roskin > > - > 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/ > - 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/
ACPI + Promise IDE = disk corruption :-(((
Hello! It's just a word of warning for those who are trying ACPI with the latest kernels. I enabled ACPI in 2.4.5-ac17 (2.4.5-ac16 works fine with the same config except ACPI). When I booted I saw a message ACPI: If experiencing system slowness, try adding "acpi=no-idle" to cmdline and after that ... reiserfs: checking transaction log (device 21:04) ... Normally it takes few seconds before the system goes further, but that time it tool much longer (one minute maybe), and the next message was something like "hde: DMA timeout" I hit reset hoping to boot the system with "acpi=no-idle", but GRUB couldn't load stage2, which resides on the root partition (reiserfs). I had to install Linux on another drive and run reiserfsck. It found many errors, fixed them all, and now I'm happily running my old system. I also checked the same kernel with "acpi=no-idle" - it works. The ACPI messages are now: ACPI: Core Subsystem version [20010208] ACPI: Subsystem enabled ACPI: System firmware supports: C2 C3 ACPI: plvl2lat=10 plvl3lat=20 ACPI: C2 enter=143 C2 exit=35 ACPI: C3 enter=858 C3 exit=71 ACPI: Not using ACPI idle ACPI: System firmware supports: S0 S1 S5 The config file is here: http://www.red-bean.com/~proski/linux/config dmesg output is here: http://www.red-bean.com/~proski/linux/dmesg Possibly important data: Kernel compiled with gcc-3.0 Motherboard Micron SE440-BX2 BIOS 4S4EB2X0.05A.0016.P15 (the latest) 1 Intel Pentium III 550MHz Root filesystem is reiserfs Root filesystem is on Promise PDC20267 ide controller Local APIC (but not IO-APIC) is used. I can make more experiments (with other hard drives) if needed. -- Regards, Pavel Roskin - 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] cleanup in drivers/mtd/ftl.c (245-ac16)
On Fri, Jun 22, 2001 at 05:21:06PM -0300, Arnaldo Carvalho de Melo wrote: > Hi Rasmus, > > I've fixed this ones and its already in 2.4.6-pre5, please take a > look and see if something is missing. These patches are very close so I'll of course retract mine[1]. The only thing I'll recommend is the printk I have in the error path. [1] Sorry about the unnecessary mailing. I am not accustomed to janitor-like patches being in Linus' kernel before Alan's :) (Arnaldo already offered an explanation for why this one happened to be.) -- Regards, Rasmus([EMAIL PROTECTED]) Smoking kills. If you're killed, you've lost a very important part of your life. -Brooke Shields, during an interview to become spokesperson for a federal anti-smoking campaign. - 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/
[ANNOUNCE] Secondary mips tree.
Hi all, We have started a secondary tree for linux mips. This tree will be to SGI mips tree as Alan Cox's tree is to linus branch. We will test and play with "experimental patches" and then in time hand them off to the main branch Ralf Baechle maintains. Also one of the main reasons for this branch was to unite several of the mips trees into one place. Anyones patches (if good) are welcomed. The site is http://www.sf.net/projects/linux-mips We also have a mailing list which instructions are on the SF page on how to join. Thank you. P.S If anyone has the mips cobalt working with 2.4.X I really like those patches. Thank you. - 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: Maintainers master list?
>I have proposed that the MAINTAINERS file should be replaced by >metadata markup in the kernel sources themselves, distributed so that >it will naturally be kept up to date by the people named in it and >mechanically gathered into a generated MAINTAINERS at make dep time. >I still think this is the right thing, and was planning to revisit the >issue after the 2.5 cutover. But it certainly doesn't have to be me that >does it, and between CML2 and the Configure.help file and countering >Microsoft's anti-open-source propaganda war I have plenty of other things >to worry about. >So if you want to take this on, I encourage you to go to it. Want a >copy of the metadata schema I wrote up? I would be happy to look at any work that you have already done on this, so feel free to send it along to me. Let's take a look at what you have and where we might be able to take this. B. - 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] cleanup in drivers/mtd/ftl.c (245-ac16)
Hi Rasmus,
I've fixed this ones and its already in 2.4.6-pre5, please take a
look and see if something is missing.
- Arnaldo
Em Fri, Jun 22, 2001 at 10:29:31PM +0200, Rasmus Andersen escreveu:
> Hi.
>
> The patch below adds one instance of vmalloc return code checking
> and a number of error path resource release cleanups in build_maps.
> It is against 245-ac16.
>
> (The vmalloc non-check was reported by the Stanford team a
> while back.)
>
>
> --- linux-245-ac16-clean/drivers/mtd/ftl.cSun May 27 22:15:23 2001
> +++ linux-245-ac16/drivers/mtd/ftl.c Fri Jun 22 22:24:09 2001
> @@ -313,6 +313,7 @@
> ssize_t retval;
> loff_t offset;
>
> +ret = -1;
> /* Set up erase unit maps */
> part->DataUnits = le16_to_cpu(part->header.NumEraseUnits) -
> part->header.NumTransferUnits;
> @@ -324,7 +325,8 @@
> part->XferInfo =
> kmalloc(part->header.NumTransferUnits * sizeof(struct xfer_info_t),
> GFP_KERNEL);
> -if (!part->XferInfo) return -1;
> +if (!part->XferInfo)
> + goto err_free_EUInfo;
>
> xvalid = xtrans = 0;
> for (i = 0; i < le16_to_cpu(part->header.NumEraseUnits); i++) {
> @@ -334,8 +336,9 @@
> (unsigned char *));
>
> if (ret)
> - return ret;
> + goto err_free_XferInfo;
>
> + ret = -1;
> /* Is this a transfer partition? */
> hdr_ok = (strcmp(header.DataOrgTuple+3, "FTL100") == 0);
> if (hdr_ok && (le16_to_cpu(header.LogicalEUN) < part->DataUnits) &&
> @@ -348,7 +351,7 @@
> if (xtrans == part->header.NumTransferUnits) {
> printk(KERN_NOTICE "ftl_cs: format error: too many "
> "transfer units!\n");
> - return -1;
> + goto err_free_XferInfo;
> }
> if (hdr_ok && (le16_to_cpu(header.LogicalEUN) == 0x)) {
> part->XferInfo[xtrans].state = XFER_PREPARED;
> @@ -369,18 +372,21 @@
> (xvalid+xtrans != le16_to_cpu(header.NumEraseUnits))) {
> printk(KERN_NOTICE "ftl_cs: format error: erase units "
> "don't add up!\n");
> - return -1;
> + goto err_free_XferInfo;
> }
>
> /* Set up virtual page map */
> blocks = le32_to_cpu(header.FormattedSize) >> header.BlockSize;
> part->VirtualBlockMap = vmalloc(blocks * sizeof(u_int32_t));
> +if (!part->VirtualBlockMap)
> + goto err_free_XferInfo;
> memset(part->VirtualBlockMap, 0xff, blocks * sizeof(u_int32_t));
> part->BlocksPerUnit = (1 << header.EraseUnitSize) >> header.BlockSize;
>
> part->bam_cache = kmalloc(part->BlocksPerUnit * sizeof(u_int32_t),
> GFP_KERNEL);
> -if (!part->bam_cache) return -1;
> +if (!part->bam_cache)
> + goto err_free_VirtualBlockMap;
>
> part->bam_index = 0x;
> part->FreeTotal = 0;
> @@ -395,7 +401,7 @@
> (unsigned char *)part->bam_cache);
>
> if (ret)
> - return ret;
> + goto err_free_bam_cache;
>
> for (j = 0; j < part->BlocksPerUnit; j++) {
> if (BLOCK_FREE(le32_to_cpu(part->bam_cache[j]))) {
> @@ -411,7 +417,17 @@
> }
>
> return 0;
> -
> +
> +err_free_bam_cache:
> +kfree(part->bam_cache);
> +err_free_VirtualBlockMap:
> +vfree(part->VirtualBlockMap);
> +err_free_XferInfo:
> +kfree(part->XferInfo);
> +err_free_EUInfo:
> +kfree(part->EUNInfo);
> +printk(KERN_ERR "ftl_cs: Out of memory.");
> +return ret;
> } /* build_maps */
>
> /*==
>
> --
> Regards,
> Rasmus([EMAIL PROTECTED])
>
> Open Source. Closed Minds. We are Slashdot.
> --Anonymous Coward
> -
> 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/
--
- Arnaldo
-
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] cleanup in drivers/mtd/ftl.c (245-ac16)
Hi.
The patch below adds one instance of vmalloc return code checking
and a number of error path resource release cleanups in build_maps.
It is against 245-ac16.
(The vmalloc non-check was reported by the Stanford team a
while back.)
--- linux-245-ac16-clean/drivers/mtd/ftl.c Sun May 27 22:15:23 2001
+++ linux-245-ac16/drivers/mtd/ftl.cFri Jun 22 22:24:09 2001
@@ -313,6 +313,7 @@
ssize_t retval;
loff_t offset;
+ret = -1;
/* Set up erase unit maps */
part->DataUnits = le16_to_cpu(part->header.NumEraseUnits) -
part->header.NumTransferUnits;
@@ -324,7 +325,8 @@
part->XferInfo =
kmalloc(part->header.NumTransferUnits * sizeof(struct xfer_info_t),
GFP_KERNEL);
-if (!part->XferInfo) return -1;
+if (!part->XferInfo)
+ goto err_free_EUInfo;
xvalid = xtrans = 0;
for (i = 0; i < le16_to_cpu(part->header.NumEraseUnits); i++) {
@@ -334,8 +336,9 @@
(unsigned char *));
if (ret)
- return ret;
+ goto err_free_XferInfo;
+ ret = -1;
/* Is this a transfer partition? */
hdr_ok = (strcmp(header.DataOrgTuple+3, "FTL100") == 0);
if (hdr_ok && (le16_to_cpu(header.LogicalEUN) < part->DataUnits) &&
@@ -348,7 +351,7 @@
if (xtrans == part->header.NumTransferUnits) {
printk(KERN_NOTICE "ftl_cs: format error: too many "
"transfer units!\n");
- return -1;
+ goto err_free_XferInfo;
}
if (hdr_ok && (le16_to_cpu(header.LogicalEUN) == 0x)) {
part->XferInfo[xtrans].state = XFER_PREPARED;
@@ -369,18 +372,21 @@
(xvalid+xtrans != le16_to_cpu(header.NumEraseUnits))) {
printk(KERN_NOTICE "ftl_cs: format error: erase units "
"don't add up!\n");
- return -1;
+ goto err_free_XferInfo;
}
/* Set up virtual page map */
blocks = le32_to_cpu(header.FormattedSize) >> header.BlockSize;
part->VirtualBlockMap = vmalloc(blocks * sizeof(u_int32_t));
+if (!part->VirtualBlockMap)
+ goto err_free_XferInfo;
memset(part->VirtualBlockMap, 0xff, blocks * sizeof(u_int32_t));
part->BlocksPerUnit = (1 << header.EraseUnitSize) >> header.BlockSize;
part->bam_cache = kmalloc(part->BlocksPerUnit * sizeof(u_int32_t),
GFP_KERNEL);
-if (!part->bam_cache) return -1;
+if (!part->bam_cache)
+ goto err_free_VirtualBlockMap;
part->bam_index = 0x;
part->FreeTotal = 0;
@@ -395,7 +401,7 @@
(unsigned char *)part->bam_cache);
if (ret)
- return ret;
+ goto err_free_bam_cache;
for (j = 0; j < part->BlocksPerUnit; j++) {
if (BLOCK_FREE(le32_to_cpu(part->bam_cache[j]))) {
@@ -411,7 +417,17 @@
}
return 0;
-
+
+err_free_bam_cache:
+kfree(part->bam_cache);
+err_free_VirtualBlockMap:
+vfree(part->VirtualBlockMap);
+err_free_XferInfo:
+kfree(part->XferInfo);
+err_free_EUInfo:
+kfree(part->EUNInfo);
+printk(KERN_ERR "ftl_cs: Out of memory.");
+return ret;
} /* build_maps */
/*==
--
Regards,
Rasmus([EMAIL PROTECTED])
Open Source. Closed Minds. We are Slashdot.
--Anonymous Coward
-
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: eepro100: wait_for_cmd_done timeout
Hi Andrey, I'm attaching the log file.. please let me know if u need other details. -Wilson * Andrey Savochkin ([EMAIL PROTECTED]) wrote: > On Thu, Jun 21, 2001 at 06:36:03PM -0700, Dionysius Wilson Almeida wrote: > > I tried inserting a udelay(1) and increasing the count ..but > > the same behaviour. > > > > any clues ? btw, i've been able to compile the redhat 7.1 intel e100 > > driver and it works fine for my card. > > Your problem is different from anyone else's, as I explained. > You see "netdev watchdog" message first. > It means that the card just stopped to transmit packets. > All other messages printed after that, including wait_for_cmd_done timeout, > are irrelevant to this problem. Your card just doesn't transmit. > > Please send me a complete log of what the kernel prints, since powering up > the computer. > > Andrey > - > 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/ -- Boy! Eucalyptus! kernel.log.gz
[PATCH] cleanup of drivers/char/ip2main.c (245ac16)
Hi.
The following patch #ifdefs a function to be in its preprocessor
scope and eliminates the use of check_region, adds '\n' to printk's,
adds checks for kmalloc and does error path resource releasing
in ip2_init_board. All in drivers/char/ip2main.c and against
245ac16.
(The kmalloc part of this was reported by the Stanford team
a while back.)
--- linux-245-ac16-clean/drivers/char/ip2main.c Sat May 19 20:58:17 2001
+++ linux-245-ac16/drivers/char/ip2main.c Fri Jun 22 21:49:08 2001
@@ -418,6 +418,7 @@
rirqs[iindx++] = irq;
}
+#ifdef MODULE
static int __init
clear_requested_irq( char irq )
{
@@ -430,6 +431,7 @@
}
return 0;
}
+#endif /* MODULE */
static int __init
have_requested_irq( char irq )
@@ -953,7 +955,7 @@
static void __init
ip2_init_board( int boardnum )
{
- int i,rc;
+ int i;
int nports = 0, nboxes = 0;
i2ChanStrPtr pCh;
i2eBordStrPtr pB = i2BoardPtrTable[boardnum];
@@ -961,24 +963,21 @@
if ( !iiInitialize ( pB ) ) {
printk ( KERN_ERR "IP2: Failed to initialize board at 0x%x, error
%d\n",
pB->i2eBase, pB->i2eError );
- kfree ( pB );
- i2BoardPtrTable[boardnum] = NULL;
- return;
+ goto err_initialize;
}
- printk(KERN_INFO "Board %d: addr=0x%x irq=%d ", boardnum + 1,
+ printk(KERN_INFO "Board %d: addr=0x%x irq=%d\n", boardnum + 1,
ip2config.addr[boardnum], ip2config.irq[boardnum] );
- if (0 != ( rc = check_region( ip2config.addr[boardnum], 8))) {
- i2BoardPtrTable[boardnum] = NULL;
- printk(KERN_ERR "bad addr=0x%x rc = %d\n",
- ip2config.addr[boardnum], rc );
- return;
+ if (!request_region( ip2config.addr[boardnum], 8, pcName )) {
+ printk(KERN_ERR "bad addr=0x%x\n",
+ ip2config.addr[boardnum] );
+ goto err_initialize;
}
- request_region( ip2config.addr[boardnum], 8, pcName );
if ( iiDownloadAll ( pB, (loadHdrStrPtr)Fip_firmware, 1, Fip_firmware_size )
!= II_DOWN_GOOD ) {
- printk ( KERN_ERR "IP2:failed to download loadware " );
+ printk ( KERN_ERR "IP2:failed to download loadware\n" );
+ goto err_release_region;
} else {
printk ( KERN_INFO "fv=%d.%d.%d lv=%d.%d.%d\n",
pB->i2ePom.e.porVersion,
@@ -993,7 +992,7 @@
printk( KERN_ERR "IP2: Unknown board type, ID = %x",
pB->i2ePom.e.porID );
nports = 0;
- goto ex_exit;
+ goto err_release_region;
break;
case POR_ID_II_4: /* IntelliPort-II, ISA-4 (4xRJ45) */
@@ -1028,8 +1027,13 @@
}
DevTableMem[boardnum] = pCh =
kmalloc( sizeof(i2ChanStr) * nports, GFP_KERNEL );
+ if ( !pCh ) {
+ printk ( KERN_ERR "(i2_init_channel:) Out of memory.\n");
+ goto err_release_region;
+ }
if ( !i2InitChannels( pB, nports, pCh ) ) {
printk(KERN_ERR "i2InitChannels failed: %d\n",pB->i2eError);
+ goto err_kmalloc;
}
pB->i2eChannelPtr = [portnum];
pB->i2eChannelCnt = ABS_MOST_PORTS;
@@ -1051,6 +1055,10 @@
}
DevTableMem[boardnum] = pCh =
kmalloc ( sizeof (i2ChanStr) * nports, GFP_KERNEL );
+ if ( !pCh ) {
+ printk ( KERN_ERR "(i2_init_channel:) Out of memory.\n");
+ goto err_kmalloc;
+ }
pB->i2eChannelPtr = pCh;
pB->i2eChannelCnt = nports;
i2InitChannels ( pB, pB->i2eChannelCnt, pCh );
@@ -1062,7 +1070,17 @@
pCh++;
}
ex_exit:
- printk ( KERN_INFO "\n" );
+ printk ( "\n" );
+ return;
+
+err_kmalloc:
+ kfree ( pCh );
+err_release_region:
+ release_region(ip2config.addr[boardnum], 8);
+err_initialize:
+ kfree ( pB );
+ i2BoardPtrTable[boardnum] = NULL;
+ return;
}
/**/
--
Regards,
Rasmus([EMAIL PROTECTED])
"The obvious mathematical breakthrough would be development of an easy way
to factor large prime numbers."
-- Bill Gates, The Road Ahead, Viking Penguin (1995)
-
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: For comment: draft BIOS use document for the kernel
Alan Cox writes: > [somebody] >> I could not find any reference to BIOS int 0x15, function 0x87, >> block-move, used to copy the kernel to above the 1 megabyte >> real-mode boundary. I think this is still used. > > I dont think the kernel has ever used it. The path has always been to > enter 32bit mode then relocate/uncompress the kernel, then run it There are several non-kernel BIOS users: lilo grub syslinux XFree86 (using virtual-8088 to run a video BIOS for a second card?) dosemu? loadlin? the boot block that reads ext2 (in 1 kB -- damn what a hack) - 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: For comment: draft BIOS use document for the kernel
Followup to: <[EMAIL PROTECTED]> By author:"Richard B. Johnson" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Fri, 22 Jun 2001, Alan Cox wrote: > > > > I could not find any reference to BIOS int 0x15, function 0x87, block- > > > move, used to copy the kernel to above the 1 megabyte real-mode > > > boundary. I think this is still used. > > > > I dont think the kernel has ever used it. The path has always been to enter > > 32bit mode then relocate/uncompress the kernel, then run it > > > > Then how does 1.44 megabytes of data from a floppy disk (that won't > fit below 1 megabyte), that is accessed in real-mode, ever get to > above 1 megabyte where it can be decompressed? > > I think LILO copies each buffer read from a below 1 Megabyte buffer > (which is the only place the floppy can put its data via the BIOS), > to above 1 megabyte using the BIOS block-move function. > This is done by LILO, which isn't part of the kernel. SYSLINUX, for example, enters protected mode directly (like the kernel itself does). -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: The latest Microsoft FUD. This time from BillG, himself.
[EMAIL PROTECTED] (Rob Landley) wrote on 22.06.01 in <[EMAIL PROTECTED]>: > On Thursday 21 June 2001 18:49, Alan Cox wrote: > > > > Except that Apple keeps the old code open. Probably because > > > they'll gain nothing from it, and at best, they can appeal to > > > the techies. > > > > A company that seems to write 'you shall not work on open source projects > > in your spare time' into its employment contracts is not what I would call > > friendly or want to work for. Im sure its only a small step to 'employees > > shall not snowboard' 'employees shall not go skiing' - all of course > > argued for the same reason as being essential to the company interest > > This IS the company that had the "I work 90 hours all the time" club with > t-shirts and everything back under Jobs in the early 80's. And far more > recently, where at least one employee got in trouble for "thinking > different' with a parody site involving famous serial killers. > > The "Proprietary frosting" model is fine for leaf-node projects like games. > But if the new layer is infrastructure other people are expected to build on > top of, then what you're really saying is "I want slaves". Hmm. This *is* the company that has at least one guy full-time working on merging their changes back into gcc (with the right Copyright assignments), and where the guy in question does discuss how to make gcc work nice with both Apple's application framework and the GPL clone of it. Oh, and one intern working right now to improve gcc's errors-and-warnings code, because that's what the gcc list came up with as a task. Sure, that's not many people in such a large company, but it's a vast difference from MS, and it's also a vast difference from the earlier Apple from the look-and-feel lawsuit age. For a while, they also paid someone for working on Debian's packaging tool (dpkg) which they now use for Darwin; at the time, that guy was practically the dpkg lead developer. And don't forget MkLinux. Apple is not another Red Hat, but they're not a Black Hat either. MfG Kai - 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: /dev/nvram driver
Tim Hockin wrote: > Who is maintaining the /dev/nvram driver? I have a couple things I want to > suggest/ask. I haven't seen any patches for ages to nvram, so I presume nobody. > What I really want to know is: should I bother making nvram_open_cnt SMP > safe, or should it just go away all together. I vote for the latter > option, unless something depends on this behavior (in which case, other > fixes are needed, because it is broken :). Once you figure out what the best behavior is (which I'm not sure of, myself), I would suggest using a semaphore in the open and release methods. Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - 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: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
On Tue, Jun 19, 2001, Dylan Griffiths <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt wrote: > > Could you load uhci with the debug=1 option? > > I did an 'insmod uhci.o debug=1' but the dmesg output did not alter. > > My easy steps to reproduce it is to 'delete selected images' in gphoto such > that there will be no images in the camera left when the operation is done. > At loast it doesn't lock up the camera like it used to :-/ > > I think this may be a problem in the dc2xx.o then, since uhci didn't reveal > any new messages. It's possible. Many cameras are touchy wrt to the commands it receives. If one is slightly wrong, some of them will just stop talking. Did you try with the usb-uhci driver as well? JE - 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/
/dev/nvram driver
Who is maintaining the /dev/nvram driver? I have a couple things I want to suggest/ask. Currently it tracks O_EXCL on open() and sets a flag, whereby no other open() calls can succeed. Is this functionality really needed? Perhaps it should just be a reader/writer model : n readers or 1 writer. In that case, should open() block on a writer, or return -EBUSY? nvram_release() calls lock_kernel() - any particular reason? various other bits (nvram_open_cnt, for example) are not SMP safe. I'm making sure it is safe now. What I really want to know is: should I bother making nvram_open_cnt SMP safe, or should it just go away all together. I vote for the latter option, unless something depends on this behavior (in which case, other fixes are needed, because it is broken :). comments? -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [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: AMD756 PCI IRQ Routing Patch 0.2.0
"Jhon H. Caicedo O." wrote: > This is an updated version of the patch for AMD756 PCI IRQ Routing, > the changes are to use the read/write_config_nybble functions, > this makes the code shorter. Looks much better, thanks! > + printk(KERN_INFO "AMD756: dev %04x:%04x, router pirq : %d get irq : %2d\n", > + dev->vendor, dev->device, pirq, irq); [...] > + printk(KERN_INFO "AMD756: dev %04x:%04x, router pirq : %d SET irq : %2d\n", > + dev->vendor, dev->device, pirq, irq); None of the other PCI IRQ routines print out IRQ routing messages, so these shouldn't either. I assume this is debugging code? Further, the printks are potentially misleading, because pirq_amd756_get might not receive a valid irq, if 'pirq' is greater than 4. Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - 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: For comment: draft BIOS use document for the kernel
Typo? > If the E820 call fails then the INT 15 AX=0xE801 service is called and the > results are sanity checked. In particular the code zeroes the CX/DX return > > values in order to detect BIOS implementations that do not set them > usable memory data. It also handles older BIOSes that return AX/BX but not > AX/BX data. > > /set them usable/set the usable/ - 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: For comment: draft BIOS use document for the kernel
Alan Cox wrote: > > > I could not find any reference to BIOS int 0x15, function 0x87, block- > > move, used to copy the kernel to above the 1 megabyte real-mode > > boundary. I think this is still used. > > I dont think the kernel has ever used it. The path has always been to enter > 32bit mode then relocate/uncompress the kernel, then run it It's in arch/i386/boot/setup.S, after label bootsect_second. It's only used with bzImage kernels and the floppy bootsector. -- Brian Gerst - 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: For comment: draft BIOS use document for the kernel
On Fri, 22 Jun 2001, Alan Cox wrote: > > I could not find any reference to BIOS int 0x15, function 0x87, block- > > move, used to copy the kernel to above the 1 megabyte real-mode > > boundary. I think this is still used. > > I dont think the kernel has ever used it. The path has always been to enter > 32bit mode then relocate/uncompress the kernel, then run it > Then how does 1.44 megabytes of data from a floppy disk (that won't fit below 1 megabyte), that is accessed in real-mode, ever get to above 1 megabyte where it can be decompressed? I think LILO copies each buffer read from a below 1 Megabyte buffer (which is the only place the floppy can put its data via the BIOS), to above 1 megabyte using the BIOS block-move function. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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/
Cleanup kbuild for aic7xxx
The existing build process for aic7xxx on Linux has several problems.
* Users have to manually select "rebuild firmware". Relying on users
to perform any action other than make *config is unacceptable. It is
far too error prone.
* Rebuilding the firmware requires lex, yacc and libdb. Not everybody
has these installed.
* The check for which libdb to use assumes that the presence of a db.h
is enough, but the overlap between glibc-devel and dbx-devel packages
means that finding a db.h is not enough, you have to confirm that the
corresponding libdb exists.
* It checks if the firmware is up to date by comparing the timestamps
on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
aic7xxx.reg. Alas, when a patch hits those files there is no
guarantee which order the files are listed in the patch so the final
timestamp order is unreliable. diff lists files in alphabetical
order but other source repository systems can generate patches in any
order. This is a problem for all generated files, not just aic7xxx.
* Shipping files which are also overwritten by users causes problems
for source control systems and can cause spurious differences when
generating patches. This is a problem for all generated files, not
just aic7xxx.
The patch below fixes all of the above issues. It does not touch the
aic7xxx code nor sequencer input, just the generated files and the
kbuild related files. The patch is approx 100Kb but most of it is the
rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
After applying this patch, normal users will not have to worry about
generating aic7xxx firmware. In particular they will not have to
select "rebuild firmware" nor will they need lex, yacc or libdb. Only
people who change one of these files
aic7xxx_reg.h_shipped
aic7xxx_seq.h_shipped
aicasm/Makefile
aicasm/aicasm.c
aicasm/aicasm.h
aicasm/aicasm_gram.y
aicasm/aicasm_insformat.h
aicasm/aicasm_scan.l
aicasm/aicasm_symbol.c
aicasm/aicasm_symbol.h
will need the extra tools. Rebuilding firmware is required if any of
those files are changed, i.e. you are working on aic7xxx firmware.
aic7xxx_{seq,reg}.h need to be added to "don't diff" lists. Now they
are always generated, instead of being partially supplied and partially
generated.
One extra action is required by anybody shipping patches to aic7xxx
firmware. Before generating a patch for new firmware, just
cd drivers/scsi/aic7xxx
sh make_sequencer ship
to generate new versions of aic7xxx_{seq,reg}.h_shipped and the related
files.
Patch is against 2.4.5-ac17 but will fit 2.4.6-pre5 with one reject.
2.4.6-pre5 has no help text for CONFIG_AIC7XXX_BUILD_FIRMWARE so the
removal fails but the rest of the patch will work.
begin 644 patch-2.4.5-ac17-aic7xxx.gz
M'XL(").!,SL``VMA;P#5O6MW&[FQ*/I9^A6])[-V[+$E]9M-SYF0#<'
MFV7Y^8V7',?^R?)A_??R87NR+;;KD\O\MW*UOBD/CXZ.=H"]R[O-:R^(O/A^%Q_')].7AZ]>O>)KA8ZUIOGC:R^,O#\_;6`MGRT4O0E:7[56"FO]_+-WU`I>
ML['B3_;KW>+_._K^17<\.ANN>@$2?CAY<[S\4\Y^_GQ\=^A"
MC,,:,0[=B*W8KQ#9SQQQO2K_VWNAH0ZZK0\?/KQ\_>7EX9%E)@D6,ZV+UN?/
MGT_DW_/EP]_9K*^^;M#MW9*34FZ6ZY65=!@['P][>/S\[F9IYW5P-7UYP#'7
M]UN&,4"J9FI7M4EG#VNVR6&]R8'_)LG>^')L].BI/$IYL<'@>)^"L\;A\'
MXM^XI:G8L[5JWP6S6L_B('F=>J_X7T+3BILRW[PYR!^*3^+'0^_@X=8[6GE,
M@,-^9S0_[TY?RXX?Z\]Y@(C[^_L5EYVW_I7?4]7IWQ=-MN7G,']=WFQ/V
MV^G=W6^PPN$KC$AL2FZ>Q/,.O=N'^X>[^_+A#7SD<=K49VS!U7JS](Z]O[[P
MCK;K_U-ZOG=TYQUM\MO2.UZ6]TQIO+^R51Z_W)?>RCNZ?UAO'KW_\3[G#Q^W
MGN"-[#\ENGNW6:T_/CV4QY_*F_M:)W9A>>_+)=LV'^E)],9OO0E\Q[;]A6U;
MX,_K6>3&9>S_5.Y9%*LI."KU6*_%#RA5'FI_UAY]?YY91OH^?URE7^=//XQ@L23L2+(/>G3ZM;Y9>
M9YG?/Y8/WMGZX?;W_*'T?E\_?O+>E@^;\L83*(='VEJGUX-ACRGFY/)]9](_
M/&)+39G/_]5[O/,>V`*W]]P8'C^5;+G_?BHW!9M^Q:;GLZ_N'@0$EBT\/B?3
M/IB$N0J/T??X<'=S4SX<'QX=>N.*Q`K7VS[=W]\]/!YZ#I_$>6>4C0:C;C^R#)Z:B#T11;4;#_\ZWMTTA
MTH$-BAND)&+&\9LD<*C-EY/E28;=3<@U95?`=*UL*BS7UC>)2V*T=(07GT
M3,]?I7%[W)5(2%Y>+XTZ%WWA_!)U^.'W/V20TY]*:3[O2G@^__P7#XC__T
MOO]'5_S`U(X[.N'_?O((@ISOGVR^NZ?'^Z?'PU?[XWJWC(MYI9GSQW++5.D/
MWIA)[6&]++TEF(WW&]A`]VS8.9\>>Z!*7(>\IVWY<,-5)K^_/S[D>MF97LX!
M\%#=/;+ZCP;%W=+-<''J_"@R!1"B_S7`4N.V%]L)]@'
M,MY^_^)J,CY_^8;]P)EXR?Z6(@5_KY;K<@A9^V4UA+ED.0V3\:L_,%?`;/QV
MO6'F_6E=?/)NUHOE@MLK8\7[5'(/Y,V8(-:;CY6)WC^46RXB[V[%[4:RPV<3
M.B#,Y9$1???T\=-K/H*9]RW3Y$7);'1P<_KE?=?WE'I?8=%
M?+)<1.S_>9`EQY^^\_[V(Z=FZ5-ZXEPJ]8(GS>$E^QPO,6V'=VV]1J[FUY`/^@L3_\\(,WV?VQTN^R0_YP[KI6ZU9-O(S9#G*$;`/N-HQ"MC_'FP14QF\5QY(
MM?JA^C10GP;X4_4A_DS\(7_[T?LK6Y6I(__+\U[H,OC^>_;CG[[[T1.`/_(D
MYC9?;U[\_6Z]?.G]@TW$\J'-B^^^>^WYU7\O?V3:^_CTL'G!?_SG'U_*V3V6
M`'W_XF(\G7/6+)EO`(W$PMWL@[\L(_G3`9GFR>F#S_\S\]!W'U[G"D!3.<
MWRJ^-F4M99O'>R5MZ3]85EG-\C_,*?!(B9S(K_>/3''<;=@V%^\35DNN9-92\W(*]WP[O/BM_PC5!(G$"TADX>P//#D=R7E_YKVIRSNH)8\.CV[6
Re: For comment: draft BIOS use document for the kernel
> Didn't you disable DMI scan recently, in favor of userspace > DMI tools? No. We still scan it but we dont print the stuff out > > should probably provide the $PIR table, even if it does not > > provide non ACPI versions of other services. > > Sorry, legacy-free => ACPI, certainly not a $PIR table IMO. Umm maybe that needs rewording. The point is that if you are building an ACPI only setup then it will generally run Linux providing you also add in the $PIR table, even though the ACPI OS's certainly won't use it > Personally I'd like to explore adding support to Linux for > the Simple Boot Flag spec. > (http://www.microsoft.com/HWDEV/desinit/simp_bios.htm See ac17. Actually its a bit buggy in ac17 but Dave Jones has been fixing it. Feel free to assist (arch/i386/kernel/bootflag.c) - 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: For comment: draft BIOS use document for the kernel
> You've described a relatively complicated procedure well in this document. > My only suggestion would be to reference the applicable source code files > throughout the text, so that it's easy to find the associated code. Thats a good idea . I'll fix that one up Thanks to all the folks who sent me bug fixes - 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: For comment: draft BIOS use document for the kernel
> I could not find any reference to BIOS int 0x15, function 0x87, block- > move, used to copy the kernel to above the 1 megabyte real-mode > boundary. I think this is still used. I dont think the kernel has ever used it. The path has always been to enter 32bit mode then relocate/uncompress the kernel, then run it - 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: For comment: draft BIOS use document for the kernel
Looks somewhat familiar. 8;) (compare http://rddunlap.home.att.net/linit/lin240_init_x86.html) (blatant plug) Some comments below. > -Original Message- > From: Alan Cox [mailto:[EMAIL PROTECTED]] > Linux 2.4 BIOS usage reference > > > Boot Sequence > - > ... > > int 0x10 service 3 is used during the boot loading sequence > to obtain the > cursor position. int 0x10 service 13 is used to display s/13/0x13/ 0x13 > loading messages > as the loading procedure continues. int 0x10 AH=0xE is used > to display a > progress bar of '=' characters during the bootstrap s/=/./'.' > Memory Sizing > - > > Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read the s/15/0x15/ > E820 map. A maximum of 32 blocks are supported by current kernels. The > 'SMAP' signature is required and tested. In addition the SMAP > signature > is restored each call, although not required by the > specification in order to handle some know BIOS bugs. > > If the E820 call fails then the INT 15 AX=0xE801 service is s/15/0x15/ > called and the > results are sanity checked. In particular the code zeroes the > CX/DX return > values in order to detect BIOS implementations that do not set them > usable memory data. It also handles older BIOSes that return > AX/BX but not AX/BX data. ??? CX/DX instead? > Peripherals > --- > ... > > Having completed video set up the hard disk data for hda and > hdb is copied > from the low memory BIOS area into the kernel tables. INT > 0x13 AH-0x15 is s/-/=/ > 32bit Bootstrap > --- > ... > > In the majority of systems the kernel will directly invoke > type 1 or type 2 > configuration. In this situation the kernel will search for a $PIR PCI > IRQ routing table in the BIOS area (0xF->0xF) with a > revision of 0x100 (1.0). However, the $PIR table is a Windows 98 requirement. Hence it is not required for newer versions of Windows and also does not apply to MP systems (unless the MP BIOS table is not being used). (http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm) $PIR *is* still used in Windows 2000 if available: http://www.microsoft.com/HWDEV/cardbus/Spir.htm > Power Management and BIOS Bugs > -- > ... > Finally the battery status querying can be disabled to work > around a small > number of BIOSes which crash when this function is used from > 32bit space. > These options can be keyed from the DMI table scanner, so > that, if we are > made aware of BIOSes requiring options set specific ways we can > automatically set the options correctly for that BIOS without user > intervention. Didn't you disable DMI scan recently, in favor of userspace DMI tools? > Future Paths > > > Intel are currently working on ACPI support for Linux. While > much of this is > functional it is not yet stable enough that vendors enable > it. Linux does > not require APM services to do minimal power management, nor > does it require > PnPBIOS services to function happily. It does however need to > know about > interrupt routing. For minimal Linux compatibility a 'legacy > free' BIOS > should probably provide the $PIR table, even if it does not > provide non ACPI versions of other services. Sorry, legacy-free => ACPI, certainly not a $PIR table IMO. Personally I'd like to explore adding support to Linux for the Simple Boot Flag spec. (http://www.microsoft.com/HWDEV/desinit/simp_bios.htm ~Randy (not speaking for Intel) - 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: For comment: draft BIOS use document for the kernel
On Fri, 22 Jun 2001, Schilling, Richard wrote: > > You've described a relatively complicated procedure well in this document. > My only suggestion would be to reference the applicable source code files > throughout the text, so that it's easy to find the associated code. > I could not find any reference to BIOS int 0x15, function 0x87, block- move, used to copy the kernel to above the 1 megabyte real-mode boundary. I think this is still used. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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/
Fair Use (Was Re: Controversy over dynamic linking -- how to end the panic)
On Thursday 21 June 2001 16:34, Craig Milo Rogers wrote: > The in-core kernel image, including a dynamically-loaded > driver, is clearly a derived work per copyright law. As above, the > portion consisting only of the dynamically-loaded driver's binary code > may or may not be a derived work per the GPL. It doesn't much matter > under the GPL, anyway, so long as the in-code kernel image isn't > "copied or distributed". It would be entirely legal to generate a patch against the copyrighted work which contains no code from the copyrighted work, and which is seperately distributed. This falls under fair use. The "fortify" folks did it for netscape navigator. Your instructions for a set of changes to someone else's work are a unique creation as long as they don't actually include any portion of the other person's work. (And things like book reviews or parody may contains small sections of the work being referred to, exactly how much is nebulous and generally decided on a case by case basis if it ever gets to court.) A tarball containing a set of source code for a new, independent module, which does not include any GPLed code, is obviously not a "derivative work" in legal terms. (It may be inspired by, but ideas aren't copyrighted, only the specific expression/implementation. You can paraphrase an encyclopedia article for a school report, etc. Just don't quote verbatim.) Now the COMPILED version is where the fun begins. Distributing a precompiled binary of this module means that GPL code was used during the compilation (at the very least header files), and that an argument could be made that technically this binary is a derivative work, and distribution of it might trigger licensing terms of the GPL. Considering that the implied use of headers (I.E. .h files) is to allow their inclusion in other programs and therefore the creation of other programs, it's possible that an argument could be made that header files (originally distributed with a .h extension by the person who issued the license in the first place) are intended to be used to create other programs, and therefore this is fair use and not the creation of a derived work. After all, the copyright holder of the code made a distinction between .c and .h files, when the functional aspects of the language dont' demand it. And normally, .h files do not directly result in code in the output (inline macros being an exception that doesn't change the overall nature and intent of the file). But it'd be a coin flip whether the judge would buy that argument. Now what LINUS seems to have done is offer an nebulous and imprecisely worded second license on at least the header files of Linux, which allows the creation of precompiled binaries as seperate items, as long as none of the existing Linux code has to be modified in any way to create these modules. (Allowing this sort of thing while still being GPL compatable with a larger work is, incidentally, the intent of the LGPL. But he didn't use it.) Binary modules created under this second license (and a verbal permission can be a legal license, as much as any oral agreement is ever likely to stand up in court), can therefore be distributed on a Linux compilation CD readily as any other piece of non-GPL code can (such as the binary-only version of netscape on the Red Hat CD's). Nobody's claiming that such an anthology is creating a derived work, merely a collective distribution mechanism for the seperately licensed entities. (Like an FTP site you can take with you.) Run-time linking of the modules with the Linux code is a seperate issue, almost certainly falling under fair use. You are not distributing the result, and you have a license for both components saying that they are in fact legal copies, therefore what you do with them is your business. (What use a legal copy is put to is NOT subject to copyright law. Contract law as part of the license terms maybe, but that's a can of worms we won't open just now, especially such fun aspects as "standing" and "informed consent"...) The only real legal question is whether Linus has the authority to offer the second license allowing the creation of non-GPL binary modules. A case could be made that he does, and not just due to the anthology copyright, but because posession really is 9/10 of the law. The "binary modules" clause has been out there for years now without being challeneged. Everybody's known about it, the statute of limitations for objecting to it has probably gone by. Everyone submitting code to Linus for a long time has been implying acceptance of his license terms for distribution of that code. A paralell could also be dawn between intellectual property law and regular property law, along the lines of homesteading. If you find an abandoned house and live in it long enough, especially if you make significant changes like fixing it up, it's considered to have been
Re: problem with select() - 2.4.5
On Fri, 22 Jun 2001, Thomas Speck wrote:
>
> Hi !
> I have a problem with reading from a serial port using select() under
> 2.4.5. What I am doing is basically the following:
>
> fd_set readfds;
> struct timeval timeout;
> int s;
>
> serialfd = open("/dev/ttyS0", O_RDWR );
>
> init_serial(B9600);
>
> timeout.tv_sec = 2; /* ! */
> timeout.tv_usec = 0;
> FD_ZERO();
> FD_SET(serialfd,);
>
> s=select(serialfd+1, , NULL, NULL, );
> ...
>
> But s is always equal to 0 even when I am sure there are data to read.
> If I use
>
> s=select(serialfd+1, NULL, , NULL, );
>
> (with the corresponding initialisation of writefds) it returns s=1 and I
> can write to the serial port. I can see that since the lights of the modem
> are flashing.
> I noticed that behavior since I tried to send some "ATZ" with the
> write-function but I never got the "OK" back.
>
> However, the same programme works under 2.2.19.
Probably I should have given the init_serial() as well; So here it is:
(it is basically the one from the serial-programming-howto)
int init_serial(tcflag_t baud)
{
struct termios tio;
tcgetattr(serialfd,);
tio.c_cflag = baud | CLOCAL;
tio.c_iflag = IGNPAR;
tio.c_oflag = 0;
tio.c_lflag = 0;
tio.c_cc[VTIME] = 0;
tio.c_cc[VMIN] = 1;
tcflush(serialfd, TCIFLUSH);
tcsetattr(serialfd,TCSANOW,);
return 0;
}
Thank you for any help
--
Thomas
-
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: aic7xxx oops with 2.4.5-ac13
On Thu, Jun 21, 2001 at 05:08:24PM +0900, Tachino Nobuhiro wrote:
Thanks,
I'll try this patch.
Jeff
>
> Hello,
>
> At Thu, 21 Jun 2001 08:15:10,
> Trevor Hemsley wrote:
> >
> > On Thu, 21 Jun 2001 03:05:02, "Jeff V. Merkey"
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Ditto. I am also seeing this oops calling the sg driver for a
> > > robotic tape library, and it also seems to happen on 2.4.4.
> >
> > In my case it appears that it was the symptom of severe bus problems.
> > About 5 minutes after I posted the initial report I discovered that
> > the cable from the back of the Nikon to the MO drive had fallen off so
> > the bus was running unterminated. Replugging it fixed teh bus error
> > and the oops.
> >
> > Looks like error handling is all fscked up...
> >
>
> I saw this oops too. The following patch is working for me, but I don't
> know this is a correct fix.
>
>
> diff -r -N -u linux.org/drivers/scsi/aic7xxx/aic7xxx_linux.c
>linux/drivers/scsi/aic7xxx/aic7xxx_linux.c
> --- linux.org/drivers/scsi/aic7xxx/aic7xxx_linux.cFri Mar 16 13:47:01 2001
> +++ linux/drivers/scsi/aic7xxx/aic7xxx_linux.cFri Mar 16 13:54:34 2001
> @@ -1872,7 +1872,9 @@
> break;
> case AC_BUS_RESET:
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0)
> - scsi_report_bus_reset(ahc->platform_data->host, channel - 'A');
> + if (ahc->platform_data->host) {
> + scsi_report_bus_reset(ahc->platform_data->host, channel - 'A');
> + }
> #endif
> break;
> default:
> -
> 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/
-
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: For comment: draft BIOS use document for the kernel
You've described a relatively complicated procedure well in this document. My only suggestion would be to reference the applicable source code files throughout the text, so that it's easy to find the associated code. Richard Schilling Webmaster / Web Integration Programmer Affiliated Health Services Mount Vernon, WA USA http://www.affiliatedhealth.org phone: 360.856.7129 > -Original Message- > From: Alan Cox [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 22, 2001 9:21 AM > To: [EMAIL PROTECTED] > Subject: For comment: draft BIOS use document for the kernel > > > > Linux 2.4 BIOS usage reference > > > Boot Sequence > - > > Linux is normally loaded either directly as a bootable floppy > image or from > hard disk via a boot loader called lilo. The kernel image is > transferred > into low memory and a parameter block above it. > > When booting from floppy disk the BIOS disk parameter tables > are replaced > by a new table set up to allow a maximum sector count of 36 > (the track size > for a 2.88Mb ED floppy) > > int 0x13, AH=0x02 is issued to to probe and find the disk geometry. > int 0x13, AH=0x00 is used to reset the floppy controller. > int 0x13, AH=0x02 is then issued repeatedly to load tracks of > data. The > boot loader ensures no issued requests cross the track > boundaries > > > int 0x10 service 3 is used during the boot loading sequence > to obtain the > cursor position. int 0x10 service 13 is used to display > loading messages > as the loading procedure continues. int 0x10 AH=0xE is used > to display a > progress bar of '=' characters during the bootstrap > > > Control is then transferred to the loaded image whether by > the floppy boot > loader or other services > > > Kernel Setup > > > The initial kernel setup executes in 16bit mode. While in > 16bit mode the > kernel calls and caches data from several 16bit calls whose > data is not > available in 32bit mode > > It then uses int 0x10 AH=0x0E in order to print initial > progress banners so > that immediate feedback on the boot status is available. The > 0x07 character > is issued as well as printable characters and is expected to > generate a > bell. > > Memory detection is done as follows, attempting to handle the various > methods that have been available over time > > Memory Sizing > - > > Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read the > E820 map. A maximum of 32 blocks are supported by current kernels. The > 'SMAP' signature is required and tested. In addition the SMAP > signature > is restored each call, although not required by the > specification in order > to handle some know BIOS bugs. > > If the E820 call fails then the INT 15 AX=0xE801 service is > called and the > results are sanity checked. In particular the code zeroes the > CX/DX return > values in order to detect BIOS implementations that do not set them > usable memory data. It also handles older BIOSes that return > AX/BX but not > AX/BX data. > > When service E801 is used the kernel assumes that usable > memory extends from > 4K to the bottom of the EBDA, and from 1Mbyte to the top of > the E801 area. > > If neither service is available then INT 0x15 AH=0x88 is > invoked in order to > get the memory size, up to 64Mb by the original IBM PC BIOS service. > > Peripherals > --- > > Having sized memory the kernel moves on to set up > peripherals. The BIOS > INT 0x16, AH=0x03 service is invoked in order to set the > keyboard repeat > rate and the video BIOS is the called to set up video modes. > > The kernel tries to identify the video in terms of its > generic features. > Initially it invokes INT 0x10 AH=0x12 to test for the > presence of EGA/VGA > as oppose to CGA/MGA/HGA hardware. > > INT 0x10 AH=0x03 is used to obtain the cursor position, and INT 0x10, > AH=0x0F is used to obtain the video page and the mode. If EGA or VGA > are present the normal BIOS locations of 0x485 and 0x484 are > used to obtain > the font size and the screen height. > > VESA BIOS video services are used to obtain the amount of > video memory > (INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0 > protected mode interface > data if available (INT 0x10, AX=0x4F0A). Users are able to > select graphical > video modes (INT 0x10 AX=0x4F02), or if not available the pre > VESA mode > setup. The presence of the VESA BIOS is checked by the VESA get mode > information call (INT 0x10 AX=0x4F01) > > Special modes will also invoke INT 0x10 AH=0x1200 (Alternate > print screen), > INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10 AH=0x1201 (to > turn off cursor > emulation) and INT 0x10 AH=0x01 (to set up the cursor). > > Having completed video set up the hard disk data for hda and > hdb is copied > from the low memory BIOS area into the kernel tables. INT > 0x13 AH-0x15 is > used to check if a second disk is present. > > INT 0x15, AH=0xC0 is invoked in order to check
Re: Linux 2.4.5-ac15 / 2.4.6-pre5
Mike Galbraith schrieb am Freitag, den 22. Juni 2001: > > 6 5 1 77232 2692 2136 47004 560 892 2048 1524 10428 285529 2 98 0 >^ > Was disk running? (I bet not.. bet it stopped just after stall began) There was no disk activity during the stall. Walter - 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/
ANN: FOLK kernel patch collection
Hi, Thought I'd drop a line to say that I've started a project, over on Sourceforge, entitled FOLK (Functionally Overloaded Linux Kernel), which basically aims to stuff as many patches as humanly possible into the Linux kernel, just to see what happens. :) This is NOT intended as a project in elegence, clean design, or any other such carp. The patches are sheer bloat. Their sole excuse for existing on the planet is that they -do- offer a chance for developers to showcase ideas alongside other people's code, and the FOLK developers (read: me) take the heat for getting things merged. If you're interested in this Cthuloid-inspired insanity, the project site is over at: http://sourceforge.net/projects/folk If you're actually crazy enough to want to help out (even if just to offer patches, make suggestions, etc) PLEASE do! I read the list (and even sometimes post) but unless it's list-specific, I'm probably going to be reached fastest if you e-mail me direct to my development e-mail address: [EMAIL PROTECTED] --== Sent via Deja.com ==-- http://www.deja.com/ - 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: For comment: draft BIOS use document for the kernel
> 1.3 Type 'apm -s' > The machine should standby > > 1.4 Wake it and type 'apm -S' > The machine should suspend According to the man pages, "apm -s" does a suspend and "apm -S" does a standby. -- Brad Pepers [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.5-ac16 -- "proc_get_inode" still unresolved in /net/wan/comx.o
On Tue, 19 Jun 2001, Miles Lane wrote: > > depmod: *** Unresolved symbols in >/lib/modules/2.4.5-ac16/kernel/drivers/net/wan/comx.o > depmod: proc_get_inode And it won't be exported. Moreover, it has a very good chance to become static. If you have the hardware in question and are willing to help with testing I would be rather grateful. I'm rewriting filesystem side of the driver (along with fixing rmmod races, etc.) and testers will be needed somewhere in the middle of next week. - 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 happened to lookup_dentry?
On Tue, 19 Jun 2001, Timur Tabi wrote:
> Well, I didn't write the driver that I'm trying to port, so it's a little
> difficult. The code in question is:
>
> struct dentry * de = lookup_dentry(zfcdb[i].fullname, NULL, LOOKUP_FOLLOW);
> if (IS_ERR(de))
> continue;
> if (de != zfcdb[i].dentry)
> {
> print("zfc: dentry changed for %s\n", zfcdb[i].fullname);
> zfc_file_init([i], de);
> }
>
> So it appears it's just checking to see if the dentry for a particular file has
> changed.
Apparently, more than that. You'll need at least vfsmount in addition to
dentry. Could you send me the source? In principle, situation looks like
you need path_init() and path_walk(), but you almost definitely will need
to make changes in more places than that.
It should be easy to fix, but it's easier to mark the places that need
fixing in the source than try to describe how to find them ;-)
-
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: Is this part of newer filesystem hierarchy?
Luigi Genoni wrote:
>
> I do not know if this is a new filesystem hierarchy, it should not be,
> at less untill lsb finishes all discussion (anyway it is similar to lsb
> standard). Your mail is a little confusing for me. Let's see if i can
> clarify my ideas.
>
> On Thu, 21 Jun 2001, D. Stimits wrote:
>
> > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > differently than just /lib/. Here is the structure I found:
> >
> > /lib/ has:
> > libc-2.2.2.so (hard link)
> > libc.so.6 (sym link to above)
> >
> > A new directory appears, /lib/i686/ (uname -m is i686):
> > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > libc.so.6 (sym link to hard link in this directory)
> >
> > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > while the 1.2 MB version is stripped.
> >
> > Here is the peculiar part that I need to find out about. My
> > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > the i686 directory is being checked if it is not listed in ld.so.conf
> > and not part of any LD path variable? I am using a non-Redhat kernel
> > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > kernel itself. My ld version:
> excuse, but if you do something like,
> ldd /bin/ls
>
> what do you get, which libc is loaded?
:~# ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
The i686 subdirectory version is visible to the linker. I don't know
how.
>
> have you got a file like /etc/ld.so.preload??
No. Nor are any preload or LD environment variables set. Something
Redhat has done is making the i686 subdirectory visible. Maybe ld
searches recursively?
> basically you can use the stripped glibc (faster), but then,
> if you have troubles and you need to debug, just set the preload file,
> or use LD_PRELOAD variable to use
> the non stripped library. In princip it is not a stupid idea,
> not that i like it, but it is not stupid.
Without any preload, it appears the linker is by default choosing the
debug version in the i686 subdirectory. Redhat must have mucked with it,
otherwise I don't see how it could be searching the i686 subdirectory
without any configuration customization (no preload, no LD environment
variables). But this is what I want to verify...where the "mucking" has
occurred, it is important to find out for some software that is used to
create custom and/or rescue disks. (alternately, to find out if there is
a predictable scheme, such as knowning ld is searching recursively, or
searches for /lib/{uname -m})
>
> > ~# ld --version
> > GNU ld 2.10.91
> > Copyright 2001 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms
> > of
> > the GNU General Public License. This program has absolutely no
> > warranty.
> > Supported emulations:
> >elf_i386
> >i386linux
> >elf_i386_glibc21
> >
> > Possibly Redhat altered ld? According to the man page, this directory
> > should not be found since it is not part of ld.so.conf, and also the
> > /lib/ version *should* be found (but isn't). What has changed, is it a
> > standard for filesystem hierarchy, or is it something distribution
> > specific? (I need to pass the answer along to someone working on
> > customized boot software that is currently being confused by this
> > distinction; there is a need to find a proper means to detect libc and
> > linker information)
> ld links dynamic libraries if the final extension is .so (usually a link),
> and uses the soname (usually a link too, created by ldconfig), for
> the binaries it generates, otherway it will use .a library archives.
> /usr/lib/libc.so (the file used by ld to link glibc), is a script. There
> are good reason for that, with libc5 it was a link to /lib/libc.so.5
> (soname).
> ld loocks for .so files as is configured
> inside of the files in /usr//lib/ldscripts
Interesting that there is a /usr/i386-glibc21-linux/ directory, but
glibc 2.2 is used. In /usr/i386-glibc21-linux/lib/ is file
libc-2.1.3.so, which matches this particular naming, but ldconfig -p
does not indicate this directory is searched. There is no ldscripts,
either as a file name or a directory name. The visible directory tree
there is:
/usr/i386-glibc21-linux/ as base, then these:
-- lib
`-- gcc-lib
`-- i386-redhat-linux
`-- 2.96
`-- include
->../../../../../lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/include
>
> please note that usually for klibraries inside of /lib, the .so link is in
> /usr/lib, or at less it
Re: mktime in include/linux
> > At 1:43 PM +0200 2001-06-22, Erik Mouw wrote: > >On Thu, Jun 21, 2001 at 10:30:40PM -0400, Rick Hohensee wrote: > >> Why does Linux have a mktime routine fully coded in linux/time.h that > >> conflicts directly with the ANSI C standard library routine of the same > >> name? It breaks a couple things against libc5, including gcc 3.0. OK, you > >> don't care about libc5. It's still pretty weird. Wierd? Weird. > > > >This has been brought up many times on this list: you are not supposed > >to include kernel headers in userland. > > That's not the problem, I think. Most of time.h, including the > definition of mktime, is #ifdef __KERNEL__, so it shouldn't be > breaking anything in userland even if you do include it. And you > might, in order to obtain the interface definition of struct > timespec. What's weird is: why is __KERNEL__ getting #defined in > Rick's userland? > > There can't, of course, be any blanket prohibition against using > kernel headers in userland. Think about ioctl.h, for example. Sounds like a clue. Thanks. Rick > -- > /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: Reg:use of file_system_type structure
On Sun, Jun 17, 2001 at 01:51:39PM +0530, SATHISH.J wrote: > > Every file system has file_system_type structure defined. Where else this > structure is referred. Does register_filesystem() refer this structure. Does > sys_mount refer to this structure by any means? For this and all your other questions, refer www.kernelnewbies.org -- Penguin : Linux 2.4.6-pre3 on an i586 When people say nothing, they don't necessarily mean nothing. - 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: Controversy over dynamic linking -- how to end the panic
On Thursday 21 June 2001 14:46, Timur Tabi wrote: > 1. License the Linux kernel under a different license that is effectively > the GPL but with additional text that clarifies the binary module issue. > Unfortunately, this license cannot be called the GPL. Politically, this > would probably be a bad idea. I thought this was what the LGPL was for? Unfortunately, it wouldn't be easy to switch from GPL to LGPL for the LInux kernel precisely BECAUSE Linus is not the sole copyright holder. (Note: Richard Stallman insisted anyone who contributed a patch of any size to GNU sign a piece of paper handing their copyright over to the FSF. Unfortunately, this created so much friction around getting patches in that it was a significant factor to GNU stalling and forking to produce Linux.) 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: For comment: draft BIOS use document for the kernel
** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Fri, 22 Jun 2001 17:20:33 +0100 (BST) > Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read the > E820 map. A maximum of 32 blocks are supported by current kernels. The > 'SMAP' signature is required and tested. In addition the SMAP signature > is restored each call, although not required by the specification in order > to handle some know BIOS bugs. FYI, in OS/2, the E820 call is made only on machines with a Pentium Pro or higher, because apparently (and this is my guess) there are some motherboards out there with older CPUs that don't return a reliable result to the E820 call. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - 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] fbgen & multiple RGBA
> the attached patch fix a problem with fbgen when changing the > RGBA components but not the depth ; fbgen would not change > the colormap in this case, where it should. It would be much easier to use a memcmp. - 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: Should __FD_SETSIZE still be set to 1024 ?
On Sat, 23 Jun 2001, Chris Wedgwood wrote: > On Fri, Jun 22, 2001 at 04:59:36PM +0200, Dag Wieers wrote: > > Is there a reason for __FD_SETSIZE to be 1024 in > linux/posix_types.h and gnu/types.h ? > Why can't we increase this number by default ? > > It might break stuff, like things that link with code that assumes it > is only 1024. So if someone wants to increase it for an application he needs to be sure that everything that it is linked with is compiled with a similar __FD_SETSIZE ? Why can you safely increase the value in Squid then ? > Shouldn't it be set to the real limit of the kernel ? > > Nah... the kernel limit is 1024^2 --- you don't want to use select > anywhere near that. Yes, but still, why 1024 ? > (And let applications define their own limit if there is a need > for one ?) > > Well, squid and friends do this anyhow. No, squid takes the lowest of both (FD_SETSIZE and SQUID_MAXFD) in main.c. And the Squid configure gets the FD_SETSIZE value from linux/posix_types.h ;( > Not only that, using a greatly increased value should be a run-time > decision, lest you want your code to break on early 2.2.x kernels and > before. I'm still not convinced that something might break, since everybody advices to increase __FD_SETSIZE before compiling Squid. And if linux/posix_types.h defines the limit of open file descriptors of the system, 1024 is (IMO) a wrong number. But then again, nobody bothered to change it... Thanks for your respons. -- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ -- «Onder voorbehoud van hetgeen niet uitdrukkelijk wordt erkend» - 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/
For comment: draft BIOS use document for the kernel
Linux 2.4 BIOS usage reference Boot Sequence - Linux is normally loaded either directly as a bootable floppy image or from hard disk via a boot loader called lilo. The kernel image is transferred into low memory and a parameter block above it. When booting from floppy disk the BIOS disk parameter tables are replaced by a new table set up to allow a maximum sector count of 36 (the track size for a 2.88Mb ED floppy) int 0x13, AH=0x02 is issued to to probe and find the disk geometry. int 0x13, AH=0x00 is used to reset the floppy controller. int 0x13, AH=0x02 is then issued repeatedly to load tracks of data. The boot loader ensures no issued requests cross the track boundaries int 0x10 service 3 is used during the boot loading sequence to obtain the cursor position. int 0x10 service 13 is used to display loading messages as the loading procedure continues. int 0x10 AH=0xE is used to display a progress bar of '=' characters during the bootstrap Control is then transferred to the loaded image whether by the floppy boot loader or other services Kernel Setup The initial kernel setup executes in 16bit mode. While in 16bit mode the kernel calls and caches data from several 16bit calls whose data is not available in 32bit mode It then uses int 0x10 AH=0x0E in order to print initial progress banners so that immediate feedback on the boot status is available. The 0x07 character is issued as well as printable characters and is expected to generate a bell. Memory detection is done as follows, attempting to handle the various methods that have been available over time Memory Sizing - Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read the E820 map. A maximum of 32 blocks are supported by current kernels. The 'SMAP' signature is required and tested. In addition the SMAP signature is restored each call, although not required by the specification in order to handle some know BIOS bugs. If the E820 call fails then the INT 15 AX=0xE801 service is called and the results are sanity checked. In particular the code zeroes the CX/DX return values in order to detect BIOS implementations that do not set them usable memory data. It also handles older BIOSes that return AX/BX but not AX/BX data. When service E801 is used the kernel assumes that usable memory extends from 4K to the bottom of the EBDA, and from 1Mbyte to the top of the E801 area. If neither service is available then INT 0x15 AH=0x88 is invoked in order to get the memory size, up to 64Mb by the original IBM PC BIOS service. Peripherals --- Having sized memory the kernel moves on to set up peripherals. The BIOS INT 0x16, AH=0x03 service is invoked in order to set the keyboard repeat rate and the video BIOS is the called to set up video modes. The kernel tries to identify the video in terms of its generic features. Initially it invokes INT 0x10 AH=0x12 to test for the presence of EGA/VGA as oppose to CGA/MGA/HGA hardware. INT 0x10 AH=0x03 is used to obtain the cursor position, and INT 0x10, AH=0x0F is used to obtain the video page and the mode. If EGA or VGA are present the normal BIOS locations of 0x485 and 0x484 are used to obtain the font size and the screen height. VESA BIOS video services are used to obtain the amount of video memory (INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0 protected mode interface data if available (INT 0x10, AX=0x4F0A). Users are able to select graphical video modes (INT 0x10 AX=0x4F02), or if not available the pre VESA mode setup. The presence of the VESA BIOS is checked by the VESA get mode information call (INT 0x10 AX=0x4F01) Special modes will also invoke INT 0x10 AH=0x1200 (Alternate print screen), INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10 AH=0x1201 (to turn off cursor emulation) and INT 0x10 AH=0x01 (to set up the cursor). Having completed video set up the hard disk data for hda and hdb is copied from the low memory BIOS area into the kernel tables. INT 0x13 AH-0x15 is used to check if a second disk is present. INT 0x15, AH=0xC0 is invoked in order to check for MCA bus machines. If an MCA systab is available the first block of the table is also saved into the kernel's own data areas. INT 0x11 is used to check for a PS/2 mouse. If this function reports that a PS/2 pointing device is present the kernel will also verify directly with the PS/2 controller itself that the mouse is attached. Power Management Linux supports APM power management. It will issue APM BIOS service calls in order to set up power management, and if present will then issue calls to the 32bit APM services after boot up. During boot the kernel issues INT 0x15 AX=0x0530 in order to do an APM BIOS installation check. It requires that a 32bit capable APM BIOS is present. Assuming a valid 32bit capable APM BIOS is reported the kernel will then issue an APM disconnect (INT 0x15 AX=0x5304) followed by a 32bit connect (INT 0x15 AX=0x5303). The
Re: The latest Microsoft FUD. This time from BillG, himself.
On Thursday 21 June 2001 18:49, Alan Cox wrote: > > Except that Apple keeps the old code open. Probably because > > they'll gain nothing from it, and at best, they can appeal to > > the techies. > > A company that seems to write 'you shall not work on open source projects > in your spare time' into its employment contracts is not what I would call > friendly or want to work for. Im sure its only a small step to 'employees > shall not snowboard' 'employees shall not go skiing' - all of course argued > for the same reason as being essential to the company interest This IS the company that had the "I work 90 hours all the time" club with t-shirts and everything back under Jobs in the early 80's. And far more recently, where at least one employee got in trouble for "thinking different' with a parody site involving famous serial killers. The "Proprietary frosting" model is fine for leaf-node projects like games. But if the new layer is infrastructure other people are expected to build on top of, then what you're really saying is "I want slaves". 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: Linux 2.4.5-ac15 / 2.4.6-pre5
On Fri, 22 Jun 2001, Walter Hofmann wrote: > Ok, I managed to press SysRq-T this time ond got a trace for my hang. > Symbols are resolved by klog. If you prefer ksymopps please tell me, I > used klog because ksymopps seems to drop all lines without symbols. Someone else might want that and/or a complete trace. I can see enough to say it looks an awful lot like a little gremlin that's been plagueing me off and on for months. (off at the moment. if he moved into your box, you can keep him.. I don't want him back:)) > There seem to be no kernel deamons in the trace? Is this normal, or is > the log buffer too small? If it is the latter, how can I increase its > size? I don't think it matters much. I strongly suspect we'd just see more of the same. Try commenting out the current->policy |= SCHED_YIELD in __alloc_pages() just for grins (more or less). > 6 5 1 77232 2692 2136 47004 560 892 2048 1524 10428 285529 2 98 0 ^ Was disk running? (I bet not.. bet it stopped just after stall began) -Mike - 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: Q serial.c
From: "Jonathan Lundell" <[EMAIL PROTECTED]> > The other CPU servicing the interrupt, was the question. cli() > doesn't affect that. This could presumably happen if shutdown() gets > run on a non-interrupt-servicing CPU, or if interrupts are > dynamically routed (eg round-robin). Ah. Missed that. Hm. Does appear to be a problem. Ted? > Where can I find the 5.05 driver? http://serial.sourceforge.net I'm not sure which version is currently in 2.4.latest, but it should be nearly 5.05. ..Stu - 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: Q serial.c
At 9:51 AM -0400 2001-06-22, Stuart MacDonald wrote: >From: "kees" <[EMAIL PROTECTED]> >> What may happen on a SMP machine if a serial port has been closed and the >> closing stage is at shutdown() in serial.c in the call to free_IRQ and >> BEFORE the IRQ is really shutdown, a new character arrives which causes an >> IRQ? Is it possible that the OTHER cpu takes this interrupt and causes a >> crash? > >I'm looking at serial-5.05/serial.c. You'll notice at the >beginning of shutdown the saveflags(); cli(); calls. >This disables interrupts. The uart will not be able to >generate IRQs even if new characters arrive. The other CPU servicing the interrupt, was the question. cli() doesn't affect that. This could presumably happen if shutdown() gets run on a non-interrupt-servicing CPU, or if interrupts are dynamically routed (eg round-robin). Where can I find the 5.05 driver? -- /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: mktime in include/linux
At 1:43 PM +0200 2001-06-22, Erik Mouw wrote: >On Thu, Jun 21, 2001 at 10:30:40PM -0400, Rick Hohensee wrote: >> Why does Linux have a mktime routine fully coded in linux/time.h that >> conflicts directly with the ANSI C standard library routine of the same >> name? It breaks a couple things against libc5, including gcc 3.0. OK, you >> don't care about libc5. It's still pretty weird. Wierd? Weird. > >This has been brought up many times on this list: you are not supposed >to include kernel headers in userland. That's not the problem, I think. Most of time.h, including the definition of mktime, is #ifdef __KERNEL__, so it shouldn't be breaking anything in userland even if you do include it. And you might, in order to obtain the interface definition of struct timespec. What's weird is: why is __KERNEL__ getting #defined in Rick's userland? There can't, of course, be any blanket prohibition against using kernel headers in userland. Think about ioctl.h, for example. -- /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/
2.4.5 kernel oops in inode.c:486
Hello, the following kernel-oops message I've found in my syslogs. As it's a production system, I'd very happy for a feedback/help. If you need further information, please let me know. As I'm not on the list, please cc: me. Christian. Christian Mudra Just remember what your mother always told you: [EMAIL PROTECTED] "When you open windows you let in bugs". === snip here === [1.] 2.4.5 kernel oops in inode.c:486 [2.] The bug itself happened on a NFS-client, running 2.4.5 while doing some file access (copy, move). The corresponding NFS-server is also running kernel 2.4.5, both machines are using knfsd with NFS v3, and the nfs-volume is mounted static, no automount. The filesystem on the server is ext2fs. [3.] knfsd, ext2, 2.4.5 [4.] Linux version 2.4.5 (root@thot) (gcc version 2.95.2 19991024 (release)) #1 Sun Jun 17 13:59:52 MEST 2001 [5.] Reading Oops report from the terminal kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[clear_inode+51/256] EFLAGS: 00010286 eax: 001b ebx: c42b9c80 ecx: c54b8000 edx: c46e8cc0 esi: c02647c0 edi: c54b9fa4 ebp: c54b9fa4 esp: c54b9eec ds: 0018 es: 0018 ss: 0018 Process ls (pid: 32694, stackpage=c54b9000) Stack: c0220fac c022100b 01e6 c42b9c80 c01407d7 c42b9c80 c297e440 c42b9c80 c0163fed c42b9c80 c013e246 c297e440 c42b9c80 c297e440 c0136c68 c297e440 c54b9f68 c01373aa c7a0d740 c54b9f68 c30f8000 Call Trace: [iput+311/336] [nfs_dentry_iput+29/48] [dput+214/336] [cached_lookup+72/96] [path_walk+1338/1936] [getname+90/160] [__user_walk+60/96] [sys_newlstat+22/112] [system_call+51/56] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 invalid operand: CPU:0 EIP:0010:[clear_inode+51/256] EFLAGS: 00010286 eax: 001b ebx: c42b9c80 ecx: c54b8000 edx: c46e8cc0 esi: c02647c0 edi: c54b9fa4 ebp: c54b9fa4 esp: c54b9eec ds: 0018 es: 0018 ss: 0018 Process ls (pid: 32694, stackpage=c54b9000) Stack: c0220fac c022100b 01e6 c42b9c80 c01407d7 c42b9c80 c297e440 c42b9c80 c0163fed c42b9c80 c013e246 c297e440 c42b9c80 c297e440 c0136c68 c297e440 c54b9f68 c01373aa c7a0d740 c54b9f68 c30f8000 Call Trace: [iput+311/336] [nfs_dentry_iput+29/48] [dput+214/336] [cached_lookup+72/96] [path_walk+1338/1936] [getname+90/160] [__user_walk+60/96] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: f6 83 f4 00 00 00 10 testb $0x10,0xf4(%ebx) Code; 000c Before first symbol c: 75 1f jne2d <_EIP+0x2d> 002d Before first symbol Code; 000e Before first symbol e: 68 e8 01 00 00push $0x1e8 Code; 0013 Before first symbol 13: 68 00 00 00 00push $0x0 [6.] n/a [7.] Environment [7.1.] Linux cheperen 2.4.5 #4 Tue Jun 19 12:16:27 MEST 2001 i686 unknown Gnu C 2.95.2 Gnu make 3.78.1 binutils 2.9.5.0.24 util-linux 2.10f mount 2.11d modutils 2.4.2 e2fsprogs 1.18 Linux C Libraryx 1 root root 4060896 Jan 17 16:37 /lib/libc.so.6 Dynamic linker (ldd) 2.1.3 Procps 2.0.6 Net-tools 1.54 Kbd0.99 Sh-utils 2.0 Modules Loaded snd-pcm-oss snd-pcm-plugin snd-mixer-oss snd-card-ens1371 snd-ens1371 snd-pcm snd-timer snd-rawmidi snd-seq-device snd-ac97-codec snd-mixer snd netlink_dev [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : AMD Athlon(tm) Processor stepping: 1 cpu MHz : 656.480 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1310.72 [7.3.] Module information (from /proc/modules): snd-pcm-oss18752 0 (autoclean) snd-pcm-plugin 15888 0 (autoclean) [snd-pcm-oss] snd-mixer-oss 5152 0 (autoclean) [snd-pcm-oss] snd-card-ens13712208 0 (autoclean) snd-ens137110032 0 (autoclean) [snd-card-ens1371] snd-pcm31264 0 (autoclean) [snd-pcm-oss snd-pcm-plugin
Re: Loop encryption module locking bug (linux-2.4.5).
> > Locking twice? But what happens if some program calls loop_set_status more
> > than once? Losetup doesn't, but if such program exists, locking is still
> > screwed.
>
> No, it calls loop_release_xfer always before init_xfer, which will release
> the "permanent" use count.
Calling lock twice in loop_set_status is not good, as long as you
don't call unlock twice too (in case that you change the transfer function):
losetup -e twofish /dev/loop0 file1 results in:
loop_open // lock not called, because no cipher selected: lock 0
loop_set_fd // has first to be bounded to file1
loop_set_status // lock called 2 times: lock 2
loop_release// unlock called: lock 1
so far so good. Now write a program that uses the same
(already configured) loop device and changes the password
(without changing the underlying file):
loop_open// lock called, because cipher selected: lock 2
loop_set_status // unlock called once, lock called twice: lock 3
loop_release // unlock called: lock 2
repeat this and the lock count will increase towards infinity.
or write a program which changes the transfer function
(without changing the underlying file):
loop_open // lock called, because cipher selected: lock1 2
loop_set_status // change transfer func:
// unlock called for transferfunc1 once
// lock called for transferfunc2 twice
// lock1 1, lock2 2
loop_release// lock1 1, lock2 1
Result: completely unused cipher module is locked.
> It's really only locking once; the issue is that it needs to keep the count
> increased while a loop device references a filter module. The other locking
> between open/release is just temporary.
A scheme in which loop_open and loop_release call lock and unlock
for the transfer function has the problem, that conceptually the
transfer function might change between a loop_open and loop_release call.
(It might even change more than once!).
If you call lock AND unlock twice in "set_status" you can resolve
this problem, but this is simply "double" locking for no clear
benefit. It only means that the locking count of a transfer function
is calculated this way:
Number of loop devices which use this function +
Number of open file descriptors of loop devices which use this function.
IMHO a transfer function doesn't belong to the application which opens
a loop device, but to the loop device itself.
I probably didn't explain it that well in my first posting, but
after applying the proposed patch, a transfer function stays locked,
as long as a loop device has a reference to it; the locking count only
is not influenced any longer by "lo_open" and "lo_release".
Locking and unlocking is done via "set_status" and unlocking is also done
via "clr_fd". So the semantic is, that a loop device can only have a transfer
function as long as it is bound. ("set_status" checks this when you try
to configure the loop device for encryption.)
so long
Ingo
PS: Lets see if I understand the SMP issue correctly:
Imagine that two processor access two different loop devices
which use the same transfer module (it has to be two different
loop devices, because the loop devices are protected against
multi processor use).
Then it is possible that two processors call the same
functions in the transfer module, which in turn access the same
global module variable, without synchronizing this accesses.
So we have lots of races right ?
-
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/
Should __FD_SETSIZE still be set to 1024 ?
Hi, Is there a reason for __FD_SETSIZE to be 1024 in linux/posix_types.h and gnu/types.h ? Why can't we increase this number by default ? Shouldn't it be set to the real limit of the kernel ? (And let applications define their own limit if there is a need for one ?) PS The LKML faq remarks that increasing this can break select. Is this still an issue ? Under what conditions ? Thanks in advance, -- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ -- «Onder voorbehoud van hetgeen niet uitdrukkelijk wordt erkend» - 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: Alan Cox quote? (was: Re: accounting for threads)
Alexander Viro writes: > BTW, proc_net_create() is also not a good idea if you block the > interrupts. Ditto for netlink_kernel_create(), AFAICS (due to > netlink_kernel_creat() -> sock_alloc() -> get_empty_inode() -> > kmem_cache_alloc() with SLAB_KERNEL). > > That, BTW, is a nice illustration - it's easy to get a preemption > point without noticing, so holding spinlocks, let alone disabling > interrupts over the large area is going to hurt like hell. Here's an idea: add a CONFIGable debug mode for spinlock/cli interaction with GFP_KERNEL and other (known) blocking operations. Keep a per-CPU flag or bitmask that's manipulated by lock/cli operations and checked by memory allocators and other key blocking operations. Generate an Oops upon violation. Make the CONFIG option initially set to 'y' for a patch level or two. 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: Alan Cox quote? (was: Re: accounting for threads)
> > A lot of OS/2 software is written with this feature in mind. I know of one > > programmer who absolutely hates Linux because it's just too difficult > > porting software to it, and the lack of decent thread support is part of > > the problem. > > Yup. OS/2 is the largest nest of trained, experienced multi-threaded > programmers. (And it takes a LOT of training experience to do threads > right.) That's why I've been trying to recruit ex-OS/2 guys over to Linux > for years now. (Most followed Java to Linux after Netscape opened up > Mozilla, but there used to be several notable holdouts...) I did some threaded programming on OS/2 and it was real pain. The main design flaw in OS/2 API is that thread can be blocked only on one condition. There is no way thread can wait for more events. For example I have a thread that processes GUI messages. It is blocked in WinGetMsg - waiting for messages from pmshell. Now another part of application needs to wake up the thread to do some things - but there is no way to wake it up because the thread can't wait for anything else than messages from pmshell. I actually had to create dummy invisible window. I send messages to that GUI thread via event queue of that window - really dirty but it can't be done otherwise. When OS/2 designers realised this API braindamage, they somewhere randomly added funtions to unblock threads waiting for variuos events - for example VioModeUndo or VioSavRedrawUndo - quite insane. Programming with select, poll and kqueue on Unix is really much better than with threads on OS/2. Mikulas - 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.5 - Kernel Panic
Hello, I've been trying to update my home (originally RedHat 7.0) linux server from the 2.4.4 kernel to the 2.4.5 kernel. On other servers I've had no problems at all, but for some reason my Gateway GP7-550 P-III at home is being stubborn. I've reconfigured and rebuilt numerous times hoping to figure out what I've done wrong, but no luck. When booting, shortly after recognizing all my hardware, I see the following. Up to the second NET4 message is normal, but after that... LVM version 0.9.1_beta2 by Heinz Mauelshagen (18/01/2001) lvm -- Driver successfully initialized NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache has tble of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) ip_tables: (c)2000 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET 4.0 EXT2-fs: unable to read superblock isofs_read_super: bread failed, dev=3:01. iso-blknum=16, block=32 Kernel panic VFS: Unable to mount root fs on 03:01 And that's where she sits until I power-cycle her. Booting to my 2.4.4 kernel there are no problems. When compiling, I originally just copied the .config from my 2.4.4 source tree, loading that with make xconfig. Due to the problem above, I then started fresh and ran into the same problem. I also tried downloading Eric Raymond's CML2, got eaten by a grue so moved to xconfig, and still same problem when booting. I'm compiling with gcc 2.95.3. Any help is appreciated. Thanks, -Jeremy - 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] fbgen & multiple RGBA
Hello, the attached patch fix a problem with fbgen when changing the RGBA components but not the depth ; fbgen would not change the colormap in this case, where it should. -- romain fbgen.patch.gz
Re: Linux 2.4.5-ac15 / 2.4.6-pre5
Mike Galbraith schrieb am Donnerstag, den 21. Juni 2001: > On Thu, 21 Jun 2001, Marcelo Tosatti wrote: > > > > 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1 >^ > > Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't > > block on IO, so they loop insanely). > > Why doesn't the VM hang the syncing of queued IO on these guys via > wait_event or such instead of trying to just let the allocation fail? > (which seems to me will only cause the allocation to be resubmitted, > effectively changing nothing but adding overhead) Does failing the > allocation in fact accomplish more than what I'm (uhoh:) assuming? Ok, I managed to press SysRq-T this time ond got a trace for my hang. Symbols are resolved by klog. If you prefer ksymopps please tell me, I used klog because ksymopps seems to drop all lines without symbols. There seem to be no kernel deamons in the trace? Is this normal, or is the log buffer too small? If it is the latter, how can I increase its size? Kernel was 2.4.6pre5 plus Rik's patch (at the end). I see the same hangs with the ac series. Walter Jun 22 15:42:09 frodo kernel: 2672 1021 1 1035 (NOTLB)1050 1004 Jun 22 15:42:10 frodo kernel: Call Trace: [sys_wait4+875/924] [system_call+51/56] Jun 22 15:42:10 frodo kernel: mysqldS 7FFF 0 1035 1021 1055 (NOTLB) Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: smbd S 7FFF 0 1050 1(NOTLB) 1051 1021 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: sshd S 7FFF 0 1051 1(NOTLB) 1060 1050 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: mysqldR 5644 1055 1035 1056 (NOTLB) Jun 22 15:42:10 frodo kernel: Call Trace: [__alloc_pages+272/656] [_alloc_pages+24/28] [__get_free_pages+10/24] [__pollwait+51/148] [pipe_poll+38/100] [do_pollfd+94/176] [do_poll+167/228] Jun 22 15:42:10 frodo kernel:[sys_poll+603/884] [system_call+51/56] Jun 22 15:42:10 frodo kernel: mysqldS C5C8A000 5704 1056 1055(NOTLB) Jun 22 15:42:10 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:10 frodo kernel: wwwoffled S C5F7BF10 2672 1060 1 4417 (NOTLB) 1064 1051 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+120/152] [process_timeout+0/76] [do_select+153/520] [sys_select+1071/1436] [system_call+51/56] Jun 22 15:42:10 frodo kernel: cron S C5F5DF7C 0 1064 1(NOTLB) 1068 1060 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+120/152] [process_timeout+0/76] [sys_nanosleep+304/428] [system_call+51/56] Jun 22 15:42:10 frodo kernel: in.identd S 7FFF 0 1068 1 1070 (NOTLB) 1083 1064 Jun 22 15:42:10 frodo kernel: Call Trace: [schedule_timeout+23/152] [wait_for_connect+308/420] [tcp_accept+134/408] [inet_accept+48/316] [sys_accept+102/244] [do_fork+1567/1756] [schedule+714/1064] Jun 22 15:42:10 frodo kernel:[restore_sigcontext+273/312] [sys_socketcall+172/476] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd R 3444 1070 1068 1081 (NOTLB) Jun 22 15:42:11 frodo kernel: Call Trace: [__alloc_pages+272/656] [_alloc_pages+24/28] [__get_free_pages+10/24] [sys_poll+310/884] [handle_IRQ_event+49/92] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C5B7A00016 1071 1070(NOTLB) 1076 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C7806000 0 1076 1070(NOTLB) 1077 1071 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C7FBC000 0 1077 1070(NOTLB) 1078 1076 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C7FB8000 2676 1078 1070(NOTLB) 1081 1077 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: in.identd S C6964000 0 1081 1070(NOTLB) 1078 Jun 22 15:42:11 frodo kernel: Call Trace: [sys_rt_sigsuspend+255/284] [system_call+51/56] Jun 22 15:42:11 frodo kernel: nscd S C739BF14 0 1083 1 1085 (NOTLB) 1098 1068 Jun 22 15:42:11 frodo kernel: Call Trace: [schedule_timeout+120/152] [process_timeout+0/76] [do_poll+55/228] [sys_poll+603/884] [sys_newstat+103/116]
Re: loop device broken in 2.4.6-pre5
[EMAIL PROTECTED] wrote: > From: Jari Ruusu <[EMAIL PROTECTED]> > > File backed loop device on 4k block size ext2 filesystem: > > # dd if=/dev/zero of=file1 bs=1024 count=10 > 10+0 records in > 10+0 records out > # losetup /dev/loop0 file1 > # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc > dd: /dev/loop0: No space left on device > 9+0 records in > 8+0 records out > # tune2fs -l /dev/hda1 2>&1| grep "Block size" > Block size: 4096 > # uname -a > Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown > > Stock 2.4.5 and 2.4.5-ac15 don't have this problem. > > I am not sure there is an error here. > > The default block size of a loop device is that of the underlying device. > There was a kernel bug that was recently fixed, where the block size > of a file backed loop device could be essentially random. > So, earlier you happened to get blocksize 1024, and you had room for > 10 blocks of size 1024. > Now you have blocksize 4096, and you have room for 2 blocks of size 4096. > There are no fractional blocks at the end of a block device. Why can't we keep the default at 1024 regardless of what the block size of underlying device is. There are some situations where all of loop device must be accessed before it is mounted (at which point the block size is set to desired value). Regards, Jari Ruusu <[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: Missing help entries in 2.4.6pre5
In article <[EMAIL PROTECTED]>, Eric S. Raymond <[EMAIL PROTECTED]> wrote: >You're a bit irritated. That's good. I *want* people who don't write >help entries for their configuration symbols to be a bit irritated. >That way, they might get around to actually doing what they ought to. You mean you actually want people to start ignoring you? Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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/
ac17 "kernel BUG at slab.c:1244!"
The first occurrence of this I didn't even notice until i checked my logs. kernel BUG at slab.c:1244! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010082 eax: 001b ebx: c187f788 ecx: 0001 edx: 2765 esi: d9a5f000 edi: d9a5f9aa ebp: 00012800 esp: d9fcbda4 ds: 0018 es: 0018 ss: 0018 Process kdeinit (pid: 993, stackpage=d9fcb000) Stack: c023d5c5 04dc d9a5f000 1000 d9a5f9aa 0246 ca0fe000 0282 d9fcbf5c 04c8 dfa43128 0007 d9fca000 0002 c01f47d7 087c 0007 d9dbef40 c01f3ed5 0840 0007 0810 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5d 8b 6b 10 58 81 e5 00 04 00 00 74 4b b8 a5 c2 0f 17 >>EIP; c0126850<= Trace; c01f47d7 Trace; c01f3ed5 Trace; c0223ab7 Trace; c01f1beb Trace; c01f1f23 Trace; c01f1faa Trace; c012e4e1 Trace; c0126d9c Trace; c013c988 <__pollwait+838/1040> Trace; c012e651 Trace; c0106ca7 <__up_wakeup+10fb/23f4> Code; c0126850 <_EIP>: Code; c0126850<= 0: 0f 0b ud2a <= Code; c0126852 2: 5dpop%ebp Code; c0126853 3: 8b 6b 10 mov0x10(%ebx),%ebp Code; c0126856 6: 58pop%eax Code; c0126857 7: 81 e5 00 04 00 00 and$0x400,%ebp Code; c012685d d: 74 4b je 5a <_EIP+0x5a> c01268aa Code; c012685f f: b8 a5 c2 0f 17mov$0x170fc2a5,%eax 1 warning and 1 error issued. Results may not be reliable. This second one was immediately after rebooting, and hard locked at getty. kernel BUG at slab.c:1244! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010082 eax: 001b ebx: c187f788 ecx: 0001 edx: 2704 esi: dfa5c000 edi: dfa5c9aa ebp: 00012800 esp: da801e2c ds: 0018 es: 0018 ss: 0018 Process mingetty (pid: 811, stackpage=da801000) Stack: c023d5c5 04dc dfa5c000 1000 dfa5c9aa 0246 0007 0001 dfa5c000 c0230b4a c030a2e0 0006 0406 c01931dd 0c3c 0007 0406 c0193e48 c198df88 0005 dfa5d000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5d 8b 6b 10 58 81 e5 00 04 00 00 74 4b b8 a5 c2 0f 17 >>EIP; c0126850<= Trace; c0230b4a <_mmx_memcpy+fa/260> Trace; c01931dd Trace; c0193e48 Trace; c0126d9c Trace; c019485e Trace; c012e932 Trace; c010fd26 Trace; c012eac6 Trace; c012db40 Trace; c012da69 Trace; c0137c5a Trace; c012dd43 Trace; c0106ca7 <__up_wakeup+10fb/23f4> Code; c0126850 <_EIP>: Code; c0126850<= 0: 0f 0b ud2a <= Code; c0126852 2: 5dpop%ebp Code; c0126853 3: 8b 6b 10 mov0x10(%ebx),%ebp Code; c0126856 6: 58pop%eax Code; c0126857 7: 81 e5 00 04 00 00 and$0x400,%ebp Code; c012685d d: 74 4b je 5a <_EIP+0x5a> c01268aa Code; c012685f f: b8 a5 c2 0f 17mov$0x170fc2a5,%eax 1 warning and 1 error issued. Results may not be reliable. This kernel was built with gcc 2.96 on an Athlon 1.33Ghz. Hope this is usefull, -- Regards, Gavin Baker - 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: Q serial.c
From: "kees" <[EMAIL PROTECTED]> > What may happen on a SMP machine if a serial port has been closed and the > closing stage is at shutdown() in serial.c in the call to free_IRQ and > BEFORE the IRQ is really shutdown, a new character arrives which causes an > IRQ? Is it possible that the OTHER cpu takes this interrupt and causes a > crash? I'm looking at serial-5.05/serial.c. You'll notice at the beginning of shutdown the saveflags(); cli(); calls. This disables interrupts. The uart will not be able to generate IRQs even if new characters arrive. ..Stu - 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/
