replay on read-only filesystem
what's the impact of mounting reiserfs as Read-Only (specified in fstab)? >From syslog ... Jun 24 01:10:30 boston kernel: Warning, log replay starting on readonly filesystem Is this a problem? Thanks, Jeff [ [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/
Making a module 2.4 compatible
I have a kernel module for a robot that was developed for the 2.0 and 2.2 kernels and does not work under 2.4. Unfortunately, the company that made it is not in business anymore. It would be nice to have it working under 2.4, so is there someplace that outlines some of the major things that would have changed so I can update the module accordingly? Thanks, --James Lamanna - 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 and gcc v3 final
On Fri, Jun 22, 2001 at 10:29:25AM +0400, Anatoly Ivanov wrote: > > I hope that lk-developers would fix it one day. Multi-string literals is a nice little ANSI C feature that appears everywhere. Why it is necessary to "fix" them? Anuradha -- Debian GNU/Linux (kernel 2.4.6-pre5) For some reason a glaze passes over people's faces when you say "Canada". Maybe we should invade South Dakota or something. -- Sandra Gotlieb, wife of the Canadian ambassador to the U.S. - 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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 06:50:33PM -0300, John R Lenton wrote: > > make-kpkg takes care of all that for you (it's part of kernel-package) It does. But only for Debian users like you and me. Regards, Anuradha -- Penguin : Linux 2.4.6-pre5 on an i586 "Language shapes the way we think, and determines what we can think about." -- B. L. Whorf - 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 04:58:51PM -0400, Tom Sightler wrote: > > 1. When running a compile, or anything else that produces lots of small disk > writes, you tend to get lots of little pauses for all the little writes to disk. > These seem to be unnoticable without the patch. > > 2. Loading programs when writing activity is occuring (even light activity like > during the compile) is noticable slower, actually any reading from disk is. > > I also ran my simple ftp test that produced the symptom I reported earlier. I > transferred a 750MB file via FTP, and with your patch sure enough disk writing > started almost immediately, but it still didn't seem to write enough data to > disk to keep up with the transfer so at approximately the 200MB mark the old > behavior still kicked in as it went into full flush mode, during the time > network activity halted, just like before. It is not uncommon to have a large number of tmp files on the disk(s) (Rik also pointed this out somewhere early in the original thread) and it is sensible to keep all of them in buffers if RAM is sufficient. Transfering _very_ large files is not _that_ common so why shouldn't that case be handled from the user space by calling sync(2)? Anuradha -- Debian GNU/Linux (kernel 2.4.6-pre5) Keep cool, but don't freeze. -- Hellman's Mayonnaise - 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: Microsoft and Xenix.
On Sat, Jun 23, 2001 at 09:41:29PM -0500, [EMAIL PROTECTED] wrote:
> Ah, yes, the RT/PC. That brings back some fond memories. My first exposure to
> Unix was with AIX on the RT. I still have some of those weird-sized RT AIX
> manuals around somewhere...
We always ran AOS on RT's. Actually, the server was the only RT, the rest
were some other model that was basically a PS/2 (286) that booted DOS, then
booted the other same chip that the RT used that was on a daughter card.
AOS was basically IBM's version of BSD. Academic Operating System.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Microsoft and Xenix.
Ah, yes, the RT/PC. That brings back some fond memories. My first exposure to Unix was with AIX on the RT. I still have some of those weird-sized RT AIX manuals around somewhere... Wayne John Adams <[EMAIL PROTECTED]> on 06/23/2001 07:49:42 PM To: [EMAIL PROTECTED] cc:(bcc: Wayne Brown/Corporate/Altec) Subject: Re: Microsoft and Xenix. On Saturday 23 June 2001 10:07, Rob Landley wrote: > Here's what I'm looking for: > > AIX was first introduced for the IBM RT/PC in 1986, which came out of the > early RISC research. It was ported to PS/2 and S/370 by SAA, and was > based on unix SVR2. (The book didn't specify whether the original > version or the version ported to SAA was based on SVR2, I'm guessing both > were.) You are partially correct. AIX (Advanced Interactive eXecutive) was built by the Boston office of Interactive Systems under contract to IBM. We had a maximum of 17 people in the effort which shipped on the RT in January 1986. Prior to that time, Interactive Systems had produced a port of System III running on the PC/XT called PC/IX which was sold via IBM. I used PC/IX to produce the software only floating point code in the first version of AIX. johna - 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: Microsoft and Xenix.
I have a complete set of the "XENIX System V" manuals and diskettes (User's Guide, User's Reference, Runtime Operating System, and Development System) for the AT&T Personal Computer 6300. The slipcases have the AT&T "Death Star" logo on the spines, and the manuals have separate copyrights listed for AT&T (1985), Microsoft (1983, 1984, 1985), and the Santa Cruz Operation (1984, 1985). I never had a 6300, but I did try booting the install diskette once on a Leading Edge Model D (PC/XT clone) and to my surprise it booted OK. Wayne "Mike Jagdis" <[EMAIL PROTECTED]> on 06/23/2001 12:57:37 PM To: "Alan Chandler" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] cc: "Rob Landley" <[EMAIL PROTECTED]> (bcc: Wayne Brown/Corporate/Altec) Subject: RE: Microsoft and Xenix. > I hope the following adds a more direct perspective on this, as I > was a user at the time. I was _almost_ at university :-). However I do have a first edition of the IBM Xenix Software Development Guide from december 1984. It has '84 IBM copyright and '83 MS copyright. The SCO stuff I have goes back to '83 - MS copyrights on it go back to '81 but that's probably just the compiler and DOS compatibility. Basically Xenix was the first MS/IBM attempt at a "real OS" for the PC. MS realised that multiuser/multitasking was less important than colour graphics for PC owners and decided to pull out of the Xenix business. IBM licensed it under their name to keep their desktop computer concept alive while the Xenix team emerged from the shake out to form SCO. Mike -- Chief Network Architect Mobile:+44 7780 608 368 Kokua Communications Ltd Office: +44 20 7292 1680 52-53 Conduit Street Fax: +44 20 7292 1681 London W1S 2YX - 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: Microsoft and Xenix.
Rob Landley <[EMAIL PROTECTED]> writes: > Ummm... GEM was the Geos stuff? (Yeah I remember it, I haven't researched > it yet though...) GEM was a gui from Digital Research I believe. Geoworks/Geos was a seperate entity. It's been a long time since I looked but they both run fine under dosemu... Eric - 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: Possible freezing bug located after ac13
On Sat, 23 Jun 2001 [EMAIL PROTECTED] wrote: > I've recently been going slightly nuts with the fact ac15, 16, and 17 > all like deadlocking/slowing to a crawl for seconds/minutes on my K6-III > with 64MB of ram and a swap space of 128MB... > > Recently I noticed something VERY odd, I'd been keeping an eye on > gkrellm while I was doing stupid things to produce the problem (a du > as root in X of / generally would always make it pop up) ... And swap > was doing I/O at the time *JUST* before when I'd either deadlock or slow > down to a crawl, and if it recovered, swap would do more I/O... > > So. I tried unmounting all swap, and suddenly everything worked fine, > although I couldn't exactly do everythign I wanted of course. > > I regression tested this, ac 16,15 and even 14 do this. ac 13 does *not* > - IMHO I think the dead swap patches introduced into 14 may be related > to the problem. 1) the dead swap cache patch should alleviate the problem, if anything 2) does this happen with 2.4.6-pre5 too ? 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/ - 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: Shared memory quantity not being reflected by /proc/meminfo
Allan Duncan writes: > Since the 2.4.x advent of shm as tmpfs or thereabouts, > /proc/meminfo shows shared memory as 0. It is in > reality not zero, and is being allocated, and shows > up in /proc/sysvipc/shm and /proc/sys/kernel/shmall > etc.. > Neither 2.4.6-pre5 nor 2.4.5-ac17 have the correct > display. You misunderstood what 2.2.xx kernels were reporting. The "shared" memory in /proc/meminfo refers to something completely unrelated to SysV shared memory. This is no longer calculated because the computation was too costly. - 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: sizeof problem in kernel modules
On Sun, 24 Jun 2001, Keith Owens wrote: > On Sat, 23 Jun 2001 21:56:06 -0400 (EDT), > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > >FYI, structures are designed to be accessed only by their member-names. > >Therefore, the compiler is free to put members at any offset. In fact, > >members, other than the first, don't even have to be in the order > >written! > > Bzzt! I don't know where people get these ideas from. Extracts from > the C9X draft. > > A structure type describes a sequentially allocated nonempty set of > member objects (and, in certain circumstances, an incomplete array), > each of which has an optionally specified name and possibly distinct > type. > > When two pointers are compared ... If the objects pointed to are > members of the same aggregate object, pointers to structure members > declared later compare greater than pointers to members declared > earlier in the structure. > > Two objects may be adjacent in memory because they are adjacent > elements of a larger array or adjacent members of a structure with no > padding between them, > > As discussed in 6.2.5, a structure is a type consisting of a sequence > of members, whose storage is allocated in an ordered sequence, > > Within a structure object, the non-bit-field members and the units > in which bit-fields reside have addresses that increase in the order > in which they are declared > > C requires that members of a structure be defined in ascending address > order as specified by the programmer. The compiler may not reorder > structure fields, although bitfields are a special case. > Previous to the "Draft" "Proposal" of C98, there were no such requirements. And so-called ANSI -C specifically declined to define any order within structures. 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/
Possible freezing bug located after ac13
I've recently been going slightly nuts with the fact ac15, 16, and 17 all like deadlocking/slowing to a crawl for seconds/minutes on my K6-III with 64MB of ram and a swap space of 128MB... Recently I noticed something VERY odd, I'd been keeping an eye on gkrellm while I was doing stupid things to produce the problem (a du as root in X of / generally would always make it pop up) ... And swap was doing I/O at the time *JUST* before when I'd either deadlock or slow down to a crawl, and if it recovered, swap would do more I/O... So. I tried unmounting all swap, and suddenly everything worked fine, although I couldn't exactly do everythign I wanted of course. I regression tested this, ac 16,15 and even 14 do this. ac 13 does *not* - IMHO I think the dead swap patches introduced into 14 may be related to the problem. Just my two cents. Tim - 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: sizeof problem in kernel modules
On Sat, 23 Jun 2001, Der Herr Hofrat wrote:
>
> Hi !
>
> can someone explain to me whats happening here ?
>
> --simple.c--
> #include
> #include
>
> struct { short x; long y; short z; }bad_struct;
> struct { long y; short x; short z; }good_struct;
>
[SNIPPED...]
> ---
>
> I would expect both structs to be 8byte in size , or atleast the same size !
> but good_struct turns out to be 8bytes and bad_struct 12 .
>
> what am I doing wrong here ?
You are assuming something that is wrong. Many programmers use
a structure as a "template", assuming that what they write is
exactly what exists in memory. This is not how the 'C' standards
are written! The only thing guaranteed by the standard is that
the first structure member will exist as the same address as the
structure itself -- nothing else.
So that structures can be used as templates, many compilers including
gcc, have non-standard extensions that can be used to "pack" structure
members. __attribute__ ((packed)) will probably do what you want.
FYI, structures are designed to be accessed only by their member-names.
Therefore, the compiler is free to put members at any offset. In fact,
members, other than the first, don't even have to be in the order
written!
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/
Re: GPIB support
On Sat, 23 Jun 2001, Wan Hing Wah wrote: > 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/ > GPIB is terribly device-specific. What board do you intend to use? National Instruments has a so-called driver for their TNT4882 on their web-site. I was never able to get it to even compile, much less work. I have a driver written for that chip. It's not GPLed, but it could be if there is enough interest. In any event, I could send you the source to try out. Just don't publish it yet. Let me know because I could use additional input for testing. In other words, if asked, I would just say that you are helping to test a driver... 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/
Re: For comment: draft BIOS use document for the kernel
Alan Cox wrote: > > 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 > If it is within the realm of the paper, I'd like to know the differences when booting from an ATAPI cdrom (or the fact that there is no difference). Or for SCSI cdrom if relevant or useful to the purposes of the paper. D. Stimits, [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/
[OOPS] linux-2.4.6-pre5aa1
I got the following oops about 41 minutes after booting into linux-2.4.6-pre5aa1. I noticed a lot of programs that were running were segfaulting so I checked 'dmesg' and found the oops.. I'm now running linux-2.4.6-pre5aa1 but this time with a more stable compiler(2.95.4) and havn't had any problems yet. ver_linux: Linux vingeren.girl 2.4.6-pre5aa1 #13 Sat Jun 23 19:03:35 EDT 2001 i686 unknown Gnu C 3.0 Gnu make 3.79.1 binutils 2.11.90.0.7 util-linux 2.11d mount 2.11d modutils 2.4.6 e2fsprogs 1.22 reiserfsprogs 3.x.0 Linux C Library2.2.3 Dynamic linker (ldd) 2.2.3 Procps 2.0.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 2.0.11 Modules Loaded i2c-piix4 gl518sm sensors i2c-core sr_mod isofs sd_mod ide-scsi ide-cd cdrom ipt_limit ipt_MASQUERADE ipt_REJECT ipt_state iptable_nat iptable_filter ip_tables ip_conntrack reiserfs ad1848 sound soundcore imm scsi_mod parport_pc parport bsd_comp ppp_deflate ppp_async ppp_generic slhc 3c59x tdfx Jun 23 00:51:26 devel kernel: Unable to handle kernel NULL pointer dereference at virtual address 0004 Jun 23 00:51:26 devel kernel: printing eip: Jun 23 00:51:26 devel kernel: c0134321 Jun 23 00:51:26 devel kernel: *pde = Jun 23 00:51:26 devel kernel: Oops: 0002 Jun 23 00:51:26 devel kernel: CPU:0 Jun 23 00:51:26 devel kernel: EIP:0010:[__remove_inode_queue+17/32] Jun 23 00:51:26 devel kernel: EFLAGS: 00010206 Jun 23 00:51:26 devel kernel: eax: ebx: c3135900 ecx: 0017 edx: Jun 23 00:51:26 devel kernel: esi: c3135a20 edi: c3135a20 ebp: c12d5dd4 esp: c4eb1c70 Jun 23 00:51:26 devel kernel: ds: 0018 es: 0018 ss: 0018 Jun 23 00:51:26 devel kernel: Process gimp (pid: 1557, stackpage=c4eb1000) Jun 23 00:51:26 devel kernel: Stack: c0136c0d c3135900 0001 c01f51f0 c10cb3a8 c3135a20 Jun 23 00:51:26 devel kernel: c10b8730 c012c0e4 c10b8730 0110 Jun 23 00:51:26 devel kernel:0a84 Jun 23 00:51:26 devel kernel: Call Trace: [try_to_free_buffers+157/352] [page_launder+1476/2560] [refill_freelist+34/80] [getblk+195/272] [ext2_alloc_branch+148/544] [ext2_get_branch+101/224] [ext2_get_block+374/1168] Jun 23 00:51:26 devel kernel:[handle_IRQ_event+58/128] [reclaim_page+1006/1152] [__alloc_pages_limit+69/160] [__alloc_pages+144/688] [__block_prepare_write+369/624] [add_to_page_cache_unique+168/176] [block_prepare_write+33/64] [ext2_get_block+0/1168] Jun 23 00:51:26 devel kernel:[generic_file_write+1040/1728] [ext2_get_block+0/1168] [sys_write+176/208] [schedule+503/1024] [system_call+51/56] Jun 23 00:51:26 devel kernel: Jun 23 00:51:26 devel kernel: Code: 89 50 04 89 02 c3 89 f6 8d bc 27 00 00 00 00 8b 54 24 04 31 Jun 23 00:52:07 devel kernel: Unable to handle kernel paging request at virtual address 9b9b Jun 23 00:52:07 devel kernel: printing eip: Jun 23 00:52:07 devel kernel: c012bbeb Jun 23 00:52:07 devel kernel: *pde = Jun 23 00:52:07 devel kernel: Oops: 0002 Jun 23 00:52:07 devel kernel: CPU:0 Jun 23 00:52:07 devel kernel: EIP:0010:[page_launder+203/2560] Jun 23 00:52:07 devel kernel: EFLAGS: 00010202 Jun 23 00:52:07 devel kernel: eax: 9b9b ebx: c4eb1cd4 ecx: edx: c12eff80 Jun 23 00:52:07 devel kernel: esi: c4eb1cd4 edi: c4eb1cb8 ebp: esp: c12eff54 Jun 23 00:52:07 devel kernel: ds: 0018 es: 0018 ss: 0018 Jun 23 00:52:07 devel kernel: Process kswapd (pid: 4, stackpage=c12ef000) Jun 23 00:52:07 devel kernel: Stack: 0ba9 Jun 23 00:52:07 devel kernel: c4eb1cd4 9b9b Jun 23 00:52:07 devel kernel: c12178ec 0040 0008e000 Jun 23 00:52:07 devel kernel: Call Trace: [do_try_to_free_pages+25/96] [kswapd+86/256] [prepare_namespace+0/16] [prepare_namespace+0/16] [kernel_thread+38/48] [kswapd+0/256] Jun 23 00:52:07 devel kernel: Jun 23 00:52:07 devel kernel: Code: 89 10 8b 44 24 0c 85 c0 74 0b 8b 1c 24 85 db 0f 88 06 09 00 Jun 23 00:52:08 devel kernel: VM: page_launder, wrong page on list. Jun 23 00:52:08 devel kernel: Unable to handle kernel paging request at virtual address 616a6198 Jun 23 00:52:08 devel kernel: printing eip: Jun 23 00:52:08 devel kernel: c012c4fe Jun 23 00:52:08 devel kernel: *pde = Jun 23 00:52:08 devel kernel: Oops: 0002 Jun 23 00:52:08 devel kernel: CPU:0 Jun 23 00:52:08 devel kernel: EIP:0010:[page_launder+2526/2560] Jun 23 00:52:08 devel kernel: EFLAGS: 00010206 Jun 23 00:52:08 devel kernel: eax: 616a6190 ebx: c4eb1cd4 ecx: 0009 edx: c935bde0 Jun 23 00:52:08 devel kernel: esi: c4e
Re: Is this part of newer filesystem hierarchy?
> The point was that Stimits says that on its Red Hat 7.1 he has no > ldscripts directory, and so no files like elf_i386.x and so on. > I was just surprised, since i know thay are all necessary to /usr/bin/ld > to work. > two libc > /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other > contains debug symbols. Ok that I dont know. The dynamic linker has changed a fair bit over time and I don't know enough about it to help - 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?
Alan Cox wrote:
>
> > glad to know this, i do wonder how does /usr/bin/ld work for red hat.
> > to my old mentality this seems red hat is going out of any resonable
> > standard.
>
> It works like /usr/bin/ld on any other platform I know of
>
> > if the same libc stripped would not run library, and they HAVE to mantein
> > a libc.so.6 linside of /lib, otherway this would be too mutch against
> > a resonable standard.
>
> bash-2.04$ ls -l /lib/libc.so.6
> lrwxrwxrwx1 root root 13 May 14 16:46 /lib/libc.so.6 ->
>libc-2.2.2.so
>
> I don't follow the discussion here.
There is a directory on RH 7.1 x86, /lib/i686/. When checking with ldd
to various applications, as to which libc they link to, it turns out
that the /lib/libc.so.6 is not used. They all seem to point at
/lib/i686/libc.so.6 (this is the version with debugging symbols) by
default. The odd thing is that there are NO LD_ style path variables set
on this system, there is NO /etc/ld.so.preload, and /etc/ld.so.conf does
not contain any reference to /lib/i686/. So there is a question of just
how it is possible for ld to use that directory and ignore /lib/ for
libc.so.6. So far the two possibilities seem to be that either the
linker was precompiled to look in the subdirectory, or else when the
linker looks at /lib/ it also recursively checks other directories (this
doesn't seem likely). The reason why it matters is because it is
confusing some custom boot floppy creation software. The original author
of that software is looking for a means to make it work correctly with
RH 7.1. The manual way for it to avoid confusion is to cd to the mount
point of the ramdisk which it builds up, into its lib directory, and sym
link the contents of the i686 subdirectory into the main lib directory.
But the original software does interesting things like checking what
ld.so.conf has, and checking what environment variables are set, but
since none of those provide any clues, the automated means remains
broken for now. Probably the next step will be manually testing for the
existence of /lib/{uname -m}/, and if it exists, sym linking it to /lib/
(these are actually relative to the mount point of the ramdisk during
creation). The boot system is designed as a customized bootdisk creation
that automatically detects various dependencies of a highly customized
linux install.
It still remains to be seen how it is that /lib/i686/libc.so.6 is used
in place of /lib/libc.so.6 (which could be deleted and RH 7.1 wouldn't
care...very strange).
D. Stimits, [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/
-
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/
cd writer problems with 2.4.5ac17
I'm thinking that this is a kernel scsi emu problem rather than a CDR problem
due to the past scsi emulation mails i've seen about previous kernels. I've
been forced to move to 2.4.x because i want to use my promise ata66 ide
controller and the 2.2 promise drivers dont work for it. My CDR is detected
as Vendor: CREATIVE Model: CD-RW RW8438ERev: FC03 by the ide-scsi
module. Now the problem is, cdrecord is very tempermental with it and it
shouldn't be. Often there are input output errors reading blank media before
writing, these lead to drive lockups that can only be recovered by power
cycling (rebooting).The cdrecord i'm using is version 1.11a04 and i'm
going to try an earlier release to see if it's a cdrecord issue in a bit but
i wanted to get responses from anyone else who may be having these problems
early if it isn't.
Errors: In dmesg this shows up.
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0
Write (10) 00 00 00 00 00 00 00 1f 00
hde: irq timeout: status=0xd0 { Busy }
hde: ATAPI reset complete
I cant get the cdrecord actual error until i reboot, but then when i do it's
random when the error does occur, just that it does after a few uses of the
burner.
on a side note. the kernel really likes to hang up when writing to a cd.
This never used to happen a few kernel releases ago.it slows everything
else down but when the cdr does write a cd, it does so without losing any
fifo buffer.
Any more info needed i'd like to give to figure this out, the thing is,
everytime this happens i have to reboot to use the CDR again. It wont even
detect unless it's power cycled and just unplugging the power cord and
putting it back in doesn't really help because it causes one of my other
drives to flip out. (did that last night.)
-
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: Microsoft and Xenix.
On Saturday 23 June 2001 10:07, Rob Landley wrote: > Here's what I'm looking for: > > AIX was first introduced for the IBM RT/PC in 1986, which came out of the > early RISC research. It was ported to PS/2 and S/370 by SAA, and was > based on unix SVR2. (The book didn't specify whether the original > version or the version ported to SAA was based on SVR2, I'm guessing both > were.) You are partially correct. AIX (Advanced Interactive eXecutive) was built by the Boston office of Interactive Systems under contract to IBM. We had a maximum of 17 people in the effort which shipped on the RT in January 1986. Prior to that time, Interactive Systems had produced a port of System III running on the PC/XT called PC/IX which was sold via IBM. I used PC/IX to produce the software only floating point code in the first version of AIX. johna - 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/
GCC3.0: Again
Again:
make[3]: Entering directory `/usr/src/linux/net/core'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-tri
graphs -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack
-boundary=2 -march=i686-c -o datagram.o datagram.c
{standard input}: Assembler messages:
{standard input}:747: Error: Junk `adcl $0x' after register
{standard input}:804: Error: Junk `adcl $0x' after register
make[3]: *** [datagram.o] Error 1
make[3]: Leaving directory `/usr/src/linux/net/core'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/net/core'
make[1]: *** [_subdir_core] Error 2
make[1]: Leaving directory `/usr/src/linux/net'
make: *** [_dir_net] Error 2
Best regards,
Alexander mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
The point was that Stimits says that on its Red Hat 7.1 he has no ldscripts directory, and so no files like elf_i386.x and so on. I was just surprised, since i know thay are all necessary to /usr/bin/ld to work. Then he was alo wondering why he has two libc /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other contains debug symbols. I can figure why, but he adfirms that /lib/i686 is not included in /etc/ld.so.conf, there is no preload configured, but this is the directory used by the loader to find the libc to load. I have to red hat installed, so i was trying to figure out how things are working on new releases (my last red hat was 6.2 when i was working at red hat Italy). Bests Luigi On Sun, 24 Jun 2001, Alan Cox wrote: > > glad to know this, i do wonder how does /usr/bin/ld work for red hat. > > to my old mentality this seems red hat is going out of any resonable > > standard. > > It works like /usr/bin/ld on any other platform I know of > > > if the same libc stripped would not run library, and they HAVE to mantein > > a libc.so.6 linside of /lib, otherway this would be too mutch against > > a resonable standard. > > bash-2.04$ ls -l /lib/libc.so.6 > lrwxrwxrwx1 root root 13 May 14 16:46 /lib/libc.so.6 -> >libc-2.2.2.so > > I don't follow the discussion here. > - 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/
Hello, your friend recommended openxxx to you
You have been invited to check out this adult site by one of your friends who visited us. our URL is http://www.openxxx.net/ enjoy, OpenXXX TEAM 2001 - 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: Microsoft and Xenix.
Rob Landley <[EMAIL PROTECTED]> writes: > That would be the X version of emacs. And there's the explanation > for the split between GNU and X emacs: it got forked and the > closed-source version had a vew years of divergent development > before opening back up, by which point it was very different to > reconcile the two code bases. No, sorry, wrong, for at least a couple of reasons reasons: 1) XEmacs, being constrained to be under the same license (GPL) as its progenitor, GNU Emacs, could never have been closed-source. 2) Lucid Emacs, the version of Emacs that becamse XEmacs, was not started until ca. 1992 I refer you to http://www.jwz.org/doc/emacs-timeline.html for documentation---JWZ was Mr. Lucid Emacs for quite a time. In 1987, there are any number of things that it could have been---I'd guess either Unipress Emacs or perhaps Gosling Emacs. 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: Missing help entries in 2.4.6pre5
[EMAIL PROTECTED] said: > There's a really simple solution to that. Eric can just make up his > own help file entries that are wildly inaccurate and actively > insulting to whoever it is who owns the symbol. Heh. Lets not be too harsh though. Chasing people who add config options without help text is a thankless task for the most part, but I'm grateful to ESR for doing it. I must admit I was actually counting on him to catch the ones I'd missed. It was only when he ignored my patch which removed an offending symbol and explained the status of a couple of false positives, and kept asking about them instead of placing them on his 'ignore' list that it became irritating. I objected, he assures me they're on the ignore list now, and we're all happy. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: For comment: draft BIOS use document for the kernel
Hi Alan. Brief critique... > 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 That looks OK. > 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 That looks OK. > 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. That looks OK. > It also handles older BIOSes that return AX/BX but not AX/BX data. Please explain that a little more clearly - it means nothing to me. > 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. That looks OK. > 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. Assuming that should be "then", that's fine. > 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) That's fine. > 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). What do you mean by "Special modes" ? > 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. Is that only for hda and hdb, or is hdc/hdd checked for as well? > 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. That's fine. > INT 0x11 is used to check for a PS/2 mouse. If this function > reports that a PS/2 pointing de
Re: GCC3.0 support: Kernel 2.4.5 compilation troubles
> Hello all! > trying to compile kernel I got following: Use 2.95 or 2.96 not gcc 3.0 if you want a peaceful time of it. If you are feeling bold and adventurous then 1. Get 2.4.6pre5 - this has the compile bug you see fixed (older gcc just missed seeing/reporting it) 2. Look back in the kernel archives and you'll find some patches for the warnings about multi-line string literals in asm blocks - 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?
> glad to know this, i do wonder how does /usr/bin/ld work for red hat. > to my old mentality this seems red hat is going out of any resonable > standard. It works like /usr/bin/ld on any other platform I know of > if the same libc stripped would not run library, and they HAVE to mantein > a libc.so.6 linside of /lib, otherway this would be too mutch against > a resonable standard. bash-2.04$ ls -l /lib/libc.so.6 lrwxrwxrwx1 root root 13 May 14 16:46 /lib/libc.so.6 -> libc-2.2.2.so I don't follow the discussion here. - 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/
GCC3.0 support: Kernel 2.4.5 compilation troubles
Hello all! trying to compile kernel I got following: make bzImage make[2]: Entering directory `/usr/src/linux/arch/i386/lib' /usr/src/linux/scripts/mkdep -D__KERNEL__ -I/usr/src/linux/include -Wall -Ws trict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mprefe rred-stack-boundary=2 -march=i686 -- checksum.S dec_and_lock.c delay.c getuser.S iodebug.c memcpy.c mmx.c old-checksum.c putuser.S strstr.c usercopy.c > .depend make[2]: Leaving directory `/usr/src/linux/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fom it-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -ma rch=i686 -c -o init/main.o init/main.c In file included from /usr/src/linux/include/net/checksum.h:33, from /usr/src/linux/include/linux/raid/md.h:34, from init/main.c:24: /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:105:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:105:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:105:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string literals are deprecated gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fom it-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -ma rch=i686 -DUTS_MACHINE='"i386"' -c -o init/version.o init/version.c make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 " -C kernel make[1]: Enteri
Re: Is this part of newer filesystem hierarchy?
On Sat, 23 Jun 2001, D. Stimits wrote:
> > > 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
> > Ok, this is the linker for compilation time, it
> > is not related to the loader for shared libraries. You can even remove
> > /usr/bin/ld, and the system will run anyway binaries, but you will not be
> > able to link compiled objects.
> > try a find for the directory ldscripts or for those files,
>
> It appears that Redhat has eliminated much of this. If I run updatedb,
> then locate, I find there is no instance of "ldscripts". Nor is there an
> instance of "i386linux" or "i386coff" that can be seen by locate. So I
> made it a wider locate, and tried for any instance of just "86linux" or
> "86coff", these also do not exist. Apparently Redhat has completely
> changed linking (looking at a backup of an older RH 6.2, these do exist,
> so I suspect the change at around 7.0).
glad to know this, i do wonder how does /usr/bin/ld work for red hat.
to my old mentality this seems red hat is going out of any resonable
standard.
>
> > >
> > > There is *no* /usr/i386-xxx except for:
> > > /usr/i386-glibc21-linux/
> > name could be different, just could you e-mail the output for
> > the command tree inside of /usr?
>
> The entire tree would be quite large. Are you looking only for
> directories (this would be a much smaller listing)? It might even
> challenge the maximum size an ISP allows before filtering it:
> 16632 directories, 258120 files
It is my own curiosity. yes if you could send me the direcotory tree of
your /usr. Just to see. Actually i know none using red hat 7.X to whom i
could ask to check, they are all slackware addicted.
>
>
> No ldscripts on the system. Through locate and awk, I can guarantee
> there is also only one ld on the system, /usr/bin/ld. It sounds like
> they did compile all other binaries from scratch, passing /lib/i686/
> explicitly.
mmm!
Again I am confused. how can the linker work?
>
>
> As far as this particular problem goes, I am trying to help the author
> of some general boot disk utilities find a good way to automatically
> detect (through perl scripts) the correct libc configuration. Telling
> users of the software that Redhat 7.1 is not supported is not an option,
> regardless of why it is a problem. What it will probably end up becoming
> is a mechanical script to test for the existence of /lib/{uname -a}/,
> and if it exists, adding it to the boot disk ld.so.conf
I would not be so scared, if you set a LD_PRELOAD_LIBRARY to
/lib/libc.so.6, you willse any binary will run anyway, because it would be
too mutch
if the same libc stripped would not run library, and they HAVE to mantein
a libc.so.6 linside of /lib, otherway this would be too mutch against
a resonable standard.
I would be happy if some guy from red hat could explain what is going on.
Luigi Genoni
-
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: Microsoft and Xenix.
On Friday 22 June 2001 18:41, Alan Chandler wrote: > I am not subscribed to the list, but I scan the archives and saw the > following. Please cc e-mail me in followups. I've had several requests to start a mailing list on this, actually... Might do so in a bit... > 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 I don't suppose you have any of those manuals still lying around? > It was more like (can't remember exactly when) 1985/1986 that Xenix got > ported to the IBM PC. Sure. Before that the PC didn't have enough Ram. Dos 2.0 was preparing the dos user base for the day when the PC -would- have enough ram. Stuff Paul Allen set in motion while he was in charge of the technical side of MS still had some momentum when he left. Initially, Microsoft's partnership with SCO was more along the lines of outsourcing development and partnering with people who knew Unix. But without Allen rooting for it, Xenix gradually stopped being strategic. Gates allowed his company to be led around by the nose by IBM, and sucked into the whole SAA/SNA thing (which DOS was the bottom tier of along with a bunch of IBM big iron, and which OS/2 emerged from as an upgrade path bringing IBM mainframe technology to higher-end PCs.) IBM had a unix, AIX, which had more or less emerged from the early RISC research (the 701 project? Lemme grab my notebook...) Ok, SAA/SNA was "Systems Application Architecture" and "Systems Network Architecture", which was launched coinciding with the big PS/2 announcement on April 2, 1987. (models 50, 60, and 80.) The SAA/SNA push also extended through the System/370 and AS400 stuff too. (I think 370's the mainframe and AS400 is the minicomputer, but I'd have to look it up. One of them (AS400?) had a database built into the OS. Interestingly, this is where SQL originated (my notes say SQL came from the System/370 but I have to double-check that, I thought the AS400 was the one with the built in database?). In either case, it was first ported to the PC as part of SAA. We also got the acronym "API" from IBM about this time.) Dos 4.0 was new, it added 723 meg disks, EMS bundled into the OS rather than an add-on (the Lotus-Intel-Microsoft Expanded Memory Specification), and "DOSShell" which conformed to the SAA graphical user interface guidelines. (Think an extremely primitive version of midnight commander.) The PS/2 model 70/80 (desktop/tower versions of same thing) were IBM's first 386 based PC boxes, which came with either DOS 3.3, DOS 4.0, OS/2 (1.0), or AIX. AIX was NOT fully SAA/SNA compliant, since Unix had its own standards that conflicted with IBM's. Either they'd have a non-standard unix, or a non-IBM os. (They kind of wound up with both, actually.) The IBM customers who insisted on Unix wanted it to comply with Unix standards, and the result is that AIX was an outsider in the big IBM cross-platform push of the 80's, and was basically sidelined within IBM as a result. It was its own little world. skip skip skip skip (notes about boca's early days... The PC was launched in August 1981, list of specs, xt, at, specs for PS/2 models 25/30, 50, 70/80, and the "pc convertable" which is a REALLY ugly laptop.) Here's what I'm looking for: AIX was first introduced for the IBM RT/PC in 1986, which came out of the early RISC research. It was ported to PS/2 and S/370 by SAA, and was based on unix SVR2. (The book didn't specify whether the original version or the version ported to SAA was based on SVR2, I'm guessing both were.) AIX was "not fully compliant" with SAA due to established and conflicting unix standards it had to be complant with, and was treated as a second class citizen by IBM because of this. It was still fairly hosed according to the rest of the unix world, but IBM mostly bent standards rather than breaking them. Hmmm... Notes on the history of shareware (pc-write/bob wallace/quiicksoft, pc-file/pc-calc/jim button/buttonware, pc-talk/andrew flugelman, apparently the chronological order is andrew-jim-bob, and bob came up with the name "shareware" because "freeware" was a trademark of Headlands Press, Inc...) Notes on the IBM Risc System 6000 launch out of a book by Jim Hoskins (which is where micro-channel came from, and also had one of the first cd-rom drives, scsi based, 380 ms access time, 150k/second, with a caddy.) Notes on the specifications of the 8080 and 8085 processors, plus the Z80 Sorry, that risc thing was the 801 project led by John Cocke, named after the building it was in and started in 1975. Ah, here's the rest of it: The IBM Person Computer RT (Risc Technology) was launched in January 1986 running AIX. The engineers (in Austin) whent on fo
Re: Alan Cox quote? (was: Re: accounting for threads)
On Friday 22 June 2001 10:46, Mikulas Patocka wrote: > 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 Sure. But you know what a race condition is, and how to spot one (in potential during coding, or during debugging.) You know how to use semaphores and when and why, and when you DON'T need them. You know about the potential for deadlocks. And most of all, you know just because you got it to run once doesn't mean it's RIGHT... > 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. OS/2 had a whole raft of problems. The fact half the system calls weren't available if you didn't boot the GUI was my personal favorite annoyance. It was a system created _for_ users instead of _by_ users. Think of the great successes in the computing world: C, Unix, the internet, the web. All of them were developed by people who were just trying to use them, as the tools they used which they modified and extended in response to their needs. This is why C is a better language than pascal, why the internet beat compuserve, and why Unix was better than OS/2. Third parties writing code "for" somebody else (to sell, as a teaching tool, etc) either leave important stuff out or add in stuff people don't want (featuritis). It's the nature of the beast: design may be clever in spurts but evolution never sleeps. (Anybody who doesn't believe that has never studied antibiotic resistant bacteria, or had to deal with cockroaches.) > Programming with select, poll and kqueue on Unix is really much better > than with threads on OS/2. I still consider the difference between threads and processes with shared resources (memory, fds, etc) to be largely semantic. > Mikulas 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
On Friday 22 June 2001 12:20, Alan Cox wrote: > 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 I seem to remember '.' characters, not '='... > 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. Hmmm... About when during the boot is this? (I get a beep from the bios long before lilo, and another when the pcmcia stuff detects a card, but that's it...) > usable memory data. It also handles older BIOSes that return AX/BX but not > AX/BX data. What does that mean? (Return garbage in AX/BX?) > 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. "then called"... > 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. "as opposed to"... > 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. Second disk or second IDE controller? (We already copied hdb from low memory, are we now confirming it?) > The kernel invokes the PCI_BIOS_PRESENT function initially, in order to > test the availability of PCI services in the firmware. Assuming this is > found them PCIBIOS_FIND_PCI_DEVICE, PCIBIOS_FIND_PCI_CLASS_CODE, > PCIBIOS_GENERATE_SPECIAL_CYCLE, PCIBIOS_READ/WRITE_CONFIG_BYTE/WORD/DWORD > calls are issued as the PCI service are configured, along with either "services are" or "service is"... > compatibility. One extension the Linux kernel makes to the official rules > for parsing this table, is that in the presence of PCI/ISA machines it will That is a totally gratuitous comma. (Okay, I'm nit-picking. It can stay if you think it can be house-trained, but I'm not feeding it.) > 4.1 Boot Linux on the system > > 4.2 Insert a PCMCIA card, ensure the kernel detects it > > 4.3 Remove the PCMCIA card, ensure the kernel detects the change > > 4.4 Insert a cardbus card, ensure the kernel detects it > > 4.5 Verify the cardbus device is usable > > 4.6 Remove the cardbus device, ensure the kernel detects it I have a 100% reproducable crash on Red Hat 7.1 if I put in a cardbus card, apm suspend, resume the system, then pop the cardbus card out. Kernel panic, every time. (I assumed it had been fixed in newer versions. I've been meaning to look into it, but it works fine with a 16 bit PCMCIA card so I just swapped my 100baseT for a 10baseT and everything's fine. The cardbus card works fine if I put it in and pop it out without suspending, and it suspend works fine by itself (Although sound never comes back after an APM suspend. I have to reboot the laptop to get sound back...) Aht he joys of the Dell inspiron 3500. Nice big screen, though... 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: Missing help entries in 2.4.6pre5
On Friday 22 June 2001 10:00, Wichert Akkerman wrote: > 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? There's a really simple solution to that. Eric can just make up his own help file entries that are wildly inaccurate and actively insulting to whoever it is who owns the symbol. Something along the lines of: "Enabling this subsystem may cause your house to burn down and your dog to explode. The prevailing opinion is that Linus was probably blackmailed into including this option by someone with naked pictures of his cat. It's useless and irritating, and just might be removed soon, so don't count on it continuing to be there. Nobody knows how to use it because they didn't provide any documentation for it." Then they're welcome to ignore it. :) Rob (As mel brooks said, it's good to be the help file maintainer...) - 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?
On Friday 22 June 2001 17:19, Timur Tabi wrote: > ** 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. This has been suggested about eight thousand times so far, and the answer is "no". I'm fairly certain there's a FAQ entry on this. The reason Linus won't do it is it conflicts with the way he works. He approves patches by reading through them in his mail reader (Pine, I think) and appending the ones he likes to a file. Then when he's done reading mail he pipes the whole file to patch and it goes into his tree. (I'm pondering an idea of sending Linus a perl script that he can use to pipe that file to patch which will split out the individual emails and forward them to an otherwise read-only "patches-linus-has-applied" mailing list. The important part of this idea is it doesn't change the way he works or make him do any extra work at all. And we get the documentation in the emails and a record of what patches got applied when. And this WOULD allow a fairly granular CVS tree to be kept up-to-date by a third party who simply subscribes to the list and automatically feeds the patches into CVS.) But Linus will NOT allow a line of code into his tree which he hasn't personally approved. He may apply patches forwarded to him by maintainers without thoroughly reading them first, but he still approves them and knows when they go in, and makes sure they don't conflict with anything else he's applying or already applied. So in a "Linux-kernel CVS tree", only Linus would have the ability to check stuff in, so he considers it a waste of time and just sends us tarballs instead. The fact Linus does this is a bottleneck, sure. But the fact we've got one guy in charge making decisions and vetoing anything that shouldn't go in is also the main reason we've got a coherent source base. Look at the ongoing fight between Rik and Andrea: even smart people who are generally right can disagree about architectural direction, and if they both make changes without somebody steering Bad Things will result. 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: Microsoft and Xenix.
On Saturday 23 June 2001 13:57, Mike Jagdis wrote: > > I hope the following adds a more direct perspective on this, as I > > was a user at the time. > > I was _almost_ at university :-). However I do have a first edition > of the IBM Xenix Software Development Guide from december 1984. It has > '84 IBM copyright and '83 MS copyright. The SCO stuff I have goes back > to '83 - MS copyrights on it go back to '81 but that's probably just > the compiler and DOS compatibility. Ooh! Ooh! I don't suppose I could borrow that? (Hmm... Driving to london isn't quite something my car's up to. For one thing, there's no gas stations in the middle of the atlantic.) The copyright dates back to when they shipped it. I believe Microsoft's license with AT&T was signed in 1979 and actual work started in 1980, but that's in a different notebook... > Basically Xenix was the first MS/IBM attempt at a "real OS" for the > PC. MS realised that multiuser/multitasking was less important than > colour graphics for PC owners and decided to pull out of the Xenix > business. IBM licensed it under their name to keep their desktop computer > concept alive while the Xenix team emerged from the shake out to form SCO. Don't make the mistake of treating IBM -OR- Microsoft as a monolithic entity. IBM had a dozen departments constantly at war with each other: Unix had its pockets of supporters at IBM, some of whom did AIX. At Microsoft, Paul Allen was the bix Unix fan. Gates was indifferent to it, and was far more interested in the Xerox Parc perspective. Both Bell Labs and Xerox Parc totally revolutionized computing. Bell Labs worked from the inside out, how the machine works and what programmers can get it to do. Multitasking, hierarchical filesystem, block and character device drivers, streams, pipes, etc. Xerox Parc worked from the outside in, how the user interacts with the computer and what they experience. Wysiwyg printing, Windows and Icons and Mice in a GUI. (Xerox also did object oriented programming, and networking which was related to both the user and system level. Then again Unix spun out of porting a flight simulator to the PDP 7. It's not QUITE that black and white...) In any case, gates was on the Xerox side and Allen was on the BTL side. When Allen left microsoft, Xenix followed soon after. (First SCO was "helping", then over the next few years the whole thing was gradually dumped on them and the umbilical severed.) Remember, Xenix hadn't made much of a splash in the PC world before 1984 because the PC simply didn't have the power to run it. YOU try doing anything useful with Unix in -LESS- than 512k of ram. That doesn't mean it wasn't having a big impact behind the scenes at Microsoft. (Similarly, windowing interfaces were Jobs's passion for 4 or 5 years before the macintosh launch, whether or not Apple's revenues or customers even knew about it.) Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Two nfsd bugs in 2.4.x
On Sunday June 24, [EMAIL PROTECTED] wrote: > Hi, > > Since I switched to the kernel nfsd I have troubles exporting my > filesystems. I think in kernel 2.2.x there was no problem, neither was > it with the userspace nfsd. Currently I run kernel 2.4.5pre1 on the > server. Sounds like you might have an old nfs-utils package. Try the latest (nfs.sourceforget.net) and see if that helps. If it doesn't, please provide complete /etc/exports and /etc/fstab. NeilBrown > > 1. When I try to boot one of my diskless clients (kernel 2.0.34), it mounts > its root fs from /opt/boot/client which is on an ext2 fs. But apparently > it hangs when it tries to access lib/ld-linux.so.1 (seen with a network > sniffer). This is a symbolic link pointing to lib/ld-linux.so.1.9.2. > In the kernel log I find: > > nfsd Security: lib/ld-linux.so.1 bad export. > > 2. I cannot any longer mount the server's /usr on certain workstations. > It works on my main workstation which currently runs kernel 2.4.5. > On other workstations I get "permission denied by server". I tried various > kernels (2.0.36, 2.2.3, 2.3.52) and various versions of mount (2.7l, 2.10o). > My /etc/exports contains the line > > /usr*.hjb.de(rw,no_root_squash) > > and all my clients are in my local DNS. The syslog shows > > rpc.mountd: getfh failed: Operation not permitted > > Any help? More info on request. > > Thanks, > hjb > -- > Pro-Linux - Germany's largest volunteer Linux support site > http://www.pro-linux.de/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - 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: Two nfsd bugs in 2.4.x
>Since I switched to the kernel nfsd I have troubles exporting my >filesystems. I think in kernel 2.2.x there was no problem, neither was >it with the userspace nfsd. Currently I run kernel 2.4.5pre1 on the >server. i have also had a few problems with nfsd when i have moved to 2.4.x (2.4.5-ac15 currently) from 2.2.x both the server and client side. problems i have been seeing include. a) if the server goes down the client sometimes does not remount the share. and it prints lots of "stale nfs handles or something" this is fine if it is remounted by hand. >1. When I try to boot one of my diskless clients (kernel 2.0.34), it mounts >its root fs from /opt/boot/client which is on an ext2 fs. But apparently >it hangs when it tries to access lib/ld-linux.so.1 (seen with a network >sniffer). This is a symbolic link pointing to lib/ld-linux.so.1.9.2. >In the kernel log I find: > >nfsd Security: lib/ld-linux.so.1 bad export. there are some options that do things with symlinks have you tried looking at some of those ? >2. I cannot any longer mount the server's /usr on certain workstations. >It works on my main workstation which currently runs kernel 2.4.5. >On other workstations I get "permission denied by server". I tried various >kernels (2.0.36, 2.2.3, 2.3.52) and various versions of mount (2.7l, 2.10o). >My /etc/exports contains the line > >/usr*.hjb.de(rw,no_root_squash) > >and all my clients are in my local DNS. The syslog shows >rpc.mountd: getfh failed: Operation not permitted hi yes i saw this it appeard to rpc.mountd that the client had already mounted the dir but the nfsd seemed to think otherwise it was returning the error to rpc.mountd rebooting the server was the only work around i found in this restarting the programs did not seem to help. eg client1: mount /home (works fine) client2: mount /home (did not work) server: restart nfs programs client2: mount /home (did not work) server: reboot client2: mount /home (works) and client1 works all the way though (except when the server is down of course) i have only seem these a few times and its been working fine since. so i think they are probably pritty hard to produce James -- - Web: http://www.stev.org Mobile: +44 07779080838 E-Mail: [EMAIL PROTECTED] 11:20pm up 3:32, 5 users, load average: 0.33, 0.39, 0.33 - 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 Thu, Jun 21, 2001 at 11:05:13PM -0400, Rick Hohensee wrote: > Richard Stallman is the creator of the license. It's his greatest work. > Linus is in no way priviledged as to interpretation of it, other than > tolerance on the part of the parties that own the copyright to the > license. Neither is RMS, though; the license is the text of the GPL, not anything RMS may have said about it since. > The GPL is about "the program". As far as I'm concerned, modules are the > kernel, "the program". The modules are *not* "the kernel". They are independent (except for header files, but you didn't make that argument, and it's by no means certain to hold up in court, especially if you don't use any code from the headers) pieces of code that happen to interact with the kernel. Why are modules, from a legal standpoint, different from user programs? And since when are derivative works under copyright law determined by the opinion of the copyright holder (much less any random third party that doesn't happen to be a court), other than to be more lenient than the law requires? > The way to stem any panic that may exist, if you want to allow binary-only > modules (which sucks*, but whatever) Sure, they suck, but only for the users that choose to use them and the providers of the modules that have to deal with the maintenance issues. What sucks even more, though, is someone else making the choice for them. > *How 'bout a nice binary-only Forth running the kernel? Metacompiling > kernel routines into the Forth dictionary and such. Sound creepy? Good. The only creepy thing here is the kernel being written in Forth; if you don't want to run it in that binary-only implementation, find (or write) a free one that will get the job done. There's no need to get the courts and lawyers involved, and no need to punish the users of the software by restricting what they can do. -Scott - 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/
Two nfsd bugs in 2.4.x
Hi, Since I switched to the kernel nfsd I have troubles exporting my filesystems. I think in kernel 2.2.x there was no problem, neither was it with the userspace nfsd. Currently I run kernel 2.4.5pre1 on the server. 1. When I try to boot one of my diskless clients (kernel 2.0.34), it mounts its root fs from /opt/boot/client which is on an ext2 fs. But apparently it hangs when it tries to access lib/ld-linux.so.1 (seen with a network sniffer). This is a symbolic link pointing to lib/ld-linux.so.1.9.2. In the kernel log I find: nfsd Security: lib/ld-linux.so.1 bad export. 2. I cannot any longer mount the server's /usr on certain workstations. It works on my main workstation which currently runs kernel 2.4.5. On other workstations I get "permission denied by server". I tried various kernels (2.0.36, 2.2.3, 2.3.52) and various versions of mount (2.7l, 2.10o). My /etc/exports contains the line /usr*.hjb.de(rw,no_root_squash) and all my clients are in my local DNS. The syslog shows rpc.mountd: getfh failed: Operation not permitted Any help? More info on request. Thanks, hjb -- Pro-Linux - Germany's largest volunteer Linux support site http://www.pro-linux.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KDSKBLED
Why does the console ioctl, KDSKBLED, work with
caps and num lock, but not scroll lock.
...
But "setleds +scroll" changes the scroll lock led without
changing the behavior of the keyboard. I then have to press
the scoll lock key twice to get the scroll lock light to turn off,
because kbd->ledflagstate is out of sync with ledstate in the kernel.
The KDSKBLED in vt.c sets ledflagstate, which is tested directly
in the keyboard driver when the status of CapsLock or NumLock is needed.
(See kbd_kern.h, vc_kbd_led().)
However, the function of the ScrollLock key is to stop output,
and the "stopped" bit lives in the tty driver, not in the kbd driver.
You can trace what happens as follows:
1. What code is generated by the ScrollLock key? Ask showkey.
2. What keysym is bound to that code? Ask dumpkeys.
3. What is the hex value of that keysym? Ask dumpkeys -l.
In step 2 you found ScrollLock, in step 3 0x0209.
Now look at keyboard.c. The 02 part of 0209 is the index in the
array key_handler[], so we are going to call do_spec().
The 09 part of 0209 is the index in spec_fn_table[], so we
are going to call hold(). Now all is clear:
static void hold(void) {
if (tty->stopped)
start_tty(tty);
else
stop_tty(tty);
}
You see what happens. The setleds command sets the led, but does
not do stop_tty(). The next press on ScrollLock does stop_tty()
(and sets the led that was on already). The next press on ScrollLock
does start_tty() and clears the led again.
Is this a bug? I don't know. Slightly confusing perhaps,
but now that it has been like this for over seven years
I don't think there is reason to change, except possibly
as part of a global change of these drivers.
> I noticed that the setleds program does not work with
> scroll lock either. In fact, it looks like it passes a
> value of zero to the KDSKBLED ioctl when I do ./setleds +num,
> which clears the num lock instead of setting it.
Works for me. Maybe you are using console-tools instead of kbd?
Andries
[cc to linux-kernel]
-
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 <[EMAIL PROTECTED]> writes: > Linux 2.4 BIOS usage reference Pretty decent. It misses a lot of hardware details that we still depend on the BIOS to reliably setup for us. I've got code that does all of this so, setup on a couple of boards so it should just be a matter of tracking it down and including it in the documentation. If there is interest I'll start tracking it down as soon as I have a free minute. Eric - 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??
Rik van Riel wrote: > > On Thu, 21 Jun 2001, Jason McMullan wrote: > > > Or heck, let's just make the VM a _real_ Neural Network, > > that self trains itself to the load you put on the system. > > Hideously complex and evil? > > Considering the amount of parameters the neural network > would have to tune, and the fact that there are no easy > parameters to tune, good luck... > Would never work with the ac-series. Not enough time to form a neural pattern between builds. There is a semi-prior art here. Unix on the Tandem (now Compaq) Helix shipped (and maybe still does) with a Neural Net for system sanity and tuning. Only problem is that the learning period usually exceeds the average time between installing releases (communications customers). 8^) Now if it was a FAST LEARNER... > > the floor, eating that stale cheese doodle. It can't do any > > worse job on VM that some of the VM patches I've seen... > > You'd be surprised. > > 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/ > > - > 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: Controversy over dynamic linking -- how to end the panic
On Thu, 21 Jun 2001 14:14:42 -0400 "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > > >As copyright holder of the Linux kernel, Linus is the only person with > >standing to sue for license violation. [...] This means > >that in order for them to lose, a court must rule that module linking > >propagates derivative-work status *and* Linus must reverse himself and > >sue. I always thought that, Linus was not the sole copyright holder on the linux kernel. Hence, didn't think hat he is not the only person to be able to sue. Could not "kernel hacker x" sue if indeed some part of his work was used in (what he assumes to be) non GPL compliant derivative work ? Scenario: hacker X write ethernet driver for card made by constructor Y. Constructor Y provide binary module to exploit super capability of their card. Could hacker X sue company Y ? (well more interresting could be to replace hacker X by company X) -- Fabrice Gautier <[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/
3C905B module/builtin lockup on 2.4.6-pre3-5
After attempting different configurations for the past 3 hours, I am at a loss. I have attempted to successfully load the 3C59x driver with kernel 2.4.6-pre5 and pre3 with no luck. As soon as the module loads, I can switch consoles, but can type nothing into any of them. I can hit the Num Lock, which will turn on and off the light, same with Caps Lock. I can hit the return key in the terminal where the insmod command was given, and it will scroll the screen, nothing more. I tried loading the module with debug=7, per the vortex.txt file, but nothing is logged anywhere. I am at a loss as to what is the problem is here. Any help is appreciated. Attached is my .config file and output from dmesg. I can try to provide any more info that might help. I will also attache output from lspci, although, the TV card has been removed, as it was sharing an IRQ with the NIC, so I wanted to eliminate any possibility that this might be part of the problem. Glenn C. Hofmann # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_ACPI=y # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUSMGR=y CONFIG_ACPI_SYS=y CONFIG_ACPI_CPU=y CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_EC is not set # CONFIG_ACPI_CMBATT is not set # CONFIG_ACPI_THERMAL is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_CFI_INTELEXT is not set # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_AMDSTD is not set # CONFIG_MTD_SHARP is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_JEDEC is not set # # Mapping drivers for chip access # # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_SUN_UFLASH is not set # CONFIG_MTD_NORA is not set # CONFIG_MTD_PNC2000 is not set # CONFIG_MTD_RPXLITE is not set # CONFIG_MTD_SC520CDP is not set # CONFIG_MTD_NETSC520 is not set # CONFIG_MTD_SBC_GXX is not set # CONFIG_MTD_ELAN_104NC is not set # CONFIG_MTD_SA1100 is not set # CONFIG_MTD_SA1100_REDBOOT_PARTITIONS is not set # CONFIG_MTD_SA1100_BOOTLDR_PARTITIONS is not set # CONFIG_MTD_DC21285 is not set # CONFIG_MTD_IQ80310 is not set # CONFIG_MTD_DBOX2 is not set # CONFIG_MTD_CSTM_MIPS_IXX is not set # CONFIG_MTD_CFI_FLAGADM is not set # CONFIG_MTD_MIXMEM is not set # CONFIG_MTD_OCTAGON is not set # CONFIG_MTD_VMAX is not set # CONFIG_MTD_OCELOT is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_DOC1000 is not set # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOCPROBE is not set # # NAND Flash Device Drivers # # CONFIG_MTD_NAND is not set # CONFIG_MTD_NAND_SPIA is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration
Re: Is this part of newer filesystem hierarchy?
Luigi Genoni wrote:
>
> On Fri, 22 Jun 2001, D. Stimits wrote:
>
> > 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
> Ok, this is the linker for compilation time, it
> is not related to the loader for shared libraries. You can even remove
> /usr/bin/ld, and the system will run anyway binaries, but you will not be
> able to link compiled objects.
> try a find for the directory ldscripts or for those files,
It appears that Redhat has eliminated much of this. If I run updatedb,
then locate, I find there is no instance of "ldscripts". Nor is there an
instance of "i386linux" or "i386coff" that can be seen by locate. So I
made it a wider locate, and tried for any instance of just "86linux" or
"86coff", these also do not exist. Apparently Redhat has completely
changed linking (looking at a backup of an older RH 6.2, these do exist,
so I suspect the change at around 7.0).
>
> elf_i386.xelf_i386.xs i386coff.xn i386linux.xbn
> elf_i386.xbn elf_i386.xu i386coff.xr i386linux.xn
> elf_i386.xn i386coff.xi386coff.xu i386linux.xr
> elf_i386.xr i386coff.xbn i386linux.x i386linux.xu
>
> you could not find the *coff* ones
> those are the configuration file (unproper definition, i ask
> excuse for my english), for /usr/bin/ld you are running
> doing ld --version.
> >
> > 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/
> name could be different, just could you e-mail the output for
> the command tree inside of /usr?
The entire tree would be quite large. Are you looking only for
directories (this would be a much smaller listing)? It might even
challenge the maximum size an ISP allows before filtering it:
16632 directories, 258120 files
> >
> > 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.
> this is another thing...
> > 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.
> and then they compiled ALL other binaries from scratch with new linker,
> passing /lib/i686/libc.so.6 explivitally, or changing the script
> /usr/lib/libc.so?
No ldscripts on the system. Through locate and awk, I can guarantee
there is also only one ld on the system, /usr/bin/ld. It sounds like
they did compile all other binaries from scratch, passing /lib/i686/
explicitly.
>
> boh! I do not know, and I am not thinking I am going to install a Red Hat
> right now (simply it is not suitable for my needs, it is a great
> distribution, of course, but it is not what my users need).
>
> want my suggestion?
> upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
> them from sources against 2.4.X kernel includes. And you wil see if it
> works how you would expect.
Part of my reason for running Redhat 7.1 (aside from liking it's X11
support) is that I expect to be testing a lot of software for
compatibility against this particular distribution. I might upgrade my
glibc from 2.2.2 to 2.2.3, but not for a while, due to the same reasons.
As far as this particular problem goes, I am trying to help the author
of some general boot disk
[OPPS] 2.4.5-ac15
Hi
when using eject to eject a cd from an atapi cd writer that had the
tray locked by cdreored (which had messed up)
i got the following opps on 2.4.5-ac15
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: HP Model: CD-Writer+ 7200 Rev: 3.01
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: ATAPIModel: CD-ROM 44X Rev: T4C2
Type: CD-ROM ANSI SCSI revision: 02
ksymoops 2.3.7 on i586 2.4.5-ac15-js1. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.5-ac15-js1/ (default)
-m /boot/System.map-2.4.5-ac15-js1 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Error (regular_file): read_system_map stat /boot/System.map-2.4.5-ac15-js1 failed
Unable to handle kernel paging request at virtual address f6f5f251
c011cd0d
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: f6f5f201 ebx: cb40e000 ecx: f6f5f1fd edx: 0050
esi: 0246 edi: 0005 ebp: cb40ff94 esp: cb40ff74
ds: 0018 es: 0018 ss: 0018
Stack: c0107a40 c0107ae4 0005 cb40ff94 cb40e000
0005 00030001 c996d202
Call Trace: [] []
Code: 83 3c 02 01 75 07 c7 04 02 00 00 00 00 8d 47 ff 0f b3 83 50
>>EIP; c011cd0d<=
Trace; c0107a40 <__up_wakeup+1ec4/2594>
Trace; c0107ae4 <__up_wakeup+1f68/2594>
Code; c011cd0d
<_EIP>:
Code; c011cd0d<=
0: 83 3c 02 01 cmpl $0x1,(%edx,%eax,1) <=
Code; c011cd11
4: 75 07 jned <_EIP+0xd> c011cd1a
Code; c011cd13
6: c7 04 02 00 00 00 00 movl $0x0,(%edx,%eax,1)
Code; c011cd1a
d: 8d 47 ff lea0x(%edi),%eax
Code; c011cd1d
10: 0f b3 83 50 00 00 00 btr%eax,0x50(%ebx)
<1>Unable to handle kernel paging request at virtual address f6f5f251
c011cd0d
*pde =
Oops:
CPU:0
EIP:0010:[]
EFLAGS: 00010082
eax: f6f5f201 ebx: cb40e000 ecx: f6f5f1fd edx: 0050
esi: 0246 edi: 0005 ebp: cb40fbb4 esp: cb40fb94
ds: 0018 es: 0018 ss: 0018
Stack: c0107a40 c0107ae4 0005 cb40fbb4 cb40e000
0005 00030001 c996d202
cbf95504 c8a6f520 c5bdb0c0 cbfc3220 c0334150 0286
Call Trace: [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] []
Code: 83 3c 02 01 75 07 c7 04 02 00 00 00 00 8d 47 ff 0f b3 83 50
>>EIP; c011cd0d<=
Trace; c0107a40 <__up_wakeup+1ec4/2594>
Trace; c0107ae4 <__up_wakeup+1f68/2594>
Trace; c01c781f
Trace; c01c4455
Trace; c01b923e
Trace; c0106e08 <__up_wakeup+128c/2594>
Trace; c01ba410
Trace; c01ba773
Trace; c01bac34
Trace; c01d4740
Trace; c01080da <__up_wakeup+255e/2594>
Trace; c010825d
Trace; c010a51e
Trace; c01080d0 <__up_wakeup+2554/2594>
Trace; c010825d
Trace; c010a51e
Trace; c01080d0 <__up_wakeup+2554/2594>
Trace; c010825d
Trace; c010a51e
Trace; c0119072
Trace; c010828f
Trace; f6f5f251
Trace; c010a51e
Trace; f6f5f251
Trace; c0107282 <__up_wakeup+1706/2594>
Trace; c011cd0d
Trace; c01128f7 <__verify_write+607/910>
Trace; c0112560 <__verify_write+270/910>
Trace; c0106e08 <__up_wakeup+128c/2594>
Trace; f6f5f1fd
Trace; f6f5f201
Trace; c011cd0d
Trace; c0107a40 <__up_wakeup+1ec4/2594>
Trace; c0107ae4 <__up_wakeup+1f68/2594>
Code; c011cd0d
<_EIP>:
Code; c011cd0d<=
0: 83 3c 02 01 cmpl $0x1,(%edx,%eax,1) <=
Code; c011cd11
4: 75 07 jned <_EIP+0xd> c011cd1a
Code; c011cd13
6: c7 04 02 00 00 00 00 movl $0x0,(%edx,%eax,1)
Code; c011cd1a
d: 8d 47 ff lea0x(%edi),%eax
Code; c011cd1d
10: 0f b3 83 50 00 00 00 btr%eax,0x50(%ebx)
<0>Kernel panic: Aiee, killing interrupt handler!
2 warnings and 1 error issued. Results may not be reliable.
--
-
Web: http://www.stev.org
Mobile: +44 07779080838
E-Mail: [EMAIL PROTECTED]
8:00pm up 12 min, 2 users, load average: 0.02, 0.39, 0.32
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
RE: Microsoft and Xenix.
> I hope the following adds a more direct perspective on this, as I > was a user at the time. I was _almost_ at university :-). However I do have a first edition of the IBM Xenix Software Development Guide from december 1984. It has '84 IBM copyright and '83 MS copyright. The SCO stuff I have goes back to '83 - MS copyrights on it go back to '81 but that's probably just the compiler and DOS compatibility. Basically Xenix was the first MS/IBM attempt at a "real OS" for the PC. MS realised that multiuser/multitasking was less important than colour graphics for PC owners and decided to pull out of the Xenix business. IBM licensed it under their name to keep their desktop computer concept alive while the Xenix team emerged from the shake out to form SCO. Mike -- Chief Network Architect Mobile: +44 7780 608 368 Kokua Communications LtdOffice: +44 20 7292 1680 52-53 Conduit StreetFax:+44 20 7292 1681 London W1S 2YX - 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] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
Em Sat, Jun 23, 2001 at 07:09:37PM +0200, Eric Lammerts escreveu:
>
> On Sat, 23 Jun 2001, Rasmus Andersen wrote:
>
> > +if (!b) {
> > + printk(" -- aborting.\n");
> > + printk(KERN_ERR "Out of memory.");
> > + return;
> > +}
>
> Why not printk(KERN_ERR "rsrc_mgr: Out of memory.\n"); ?
> Then at least people will know what it was that ran out of memory.
Better yet:
printk(KERN_ERR __FUNCTION__ "Out of memory.");
Then if you move the code to other function or if you change the name of
the function you don't have to go all over the code doing
s/old_function_name/new_function_name/g
- 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/
HPT370 driver problems
People, I have an IWill IDE Raid card with the Highpoint HPT370 Chip. I am running this on a Dual Processor board (800MHz PIIIs) with a Mandrake 8.0 Disrtibution (2.4.3 Kernel). 200MB of RAM and all slots filled with lots of cards. I was glad to see that Linux auto-detected the IDE/Raid card. The initial hardware configuration had two 40G IBM drives (7200RPM UDMA100) each attached as the IDE Master (using cable select) of the primary and secondary IDE interfaces as this is the optimum for two drives. I then used the md/meta tools to stripe the two. Then I started to migrate data. This all went well untill I decided to check stuff with diff. Well, diff found many files to be different. I tried all the hdparm settings to no avail. I tried reiserfs to no avail. I tried swithching to LVM to no avail. I pulled out a processor, still the same result (I then broke the slot1 socket trying to put it back in -ooh my wallet hurts!). So I then focussed on looking at the type of corruption. It's approximately 2 bytes in 300 megs -so it's probably a dreaded off-by-one. The real problem with this one is that it was hard to re-produce. But I then decided to isolate the drives and found that operations on individual drives were OK, but if you tried to use the two together, pa-tang! Now here's the interesting bit; I connected the two drives onto the same cable (and therefore interface). It worked without fault. No corruptions. So I guess the problem is at the driver level when inter-working across the primary and secondary IDE interfaces. Has anyone else seen this. Any patches/workarounds? -cos I want to add another two drives. TIA, Ed-T. - 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] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sat, 23 Jun 2001, Rasmus Andersen wrote:
> +if (!b) {
> + printk(" -- aborting.\n");
> + printk(KERN_ERR "Out of memory.");
> + return;
> +}
Why not printk(KERN_ERR "rsrc_mgr: Out of memory.\n"); ?
Then at least people will know what it was that ran out of memory.
Eric
-
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.
Alan Cox wrote: > > > > Do they include the source? There's a CD of source that you can buy > > > for $20 but gcc isn't listed > > > > I'm not sure if they are allowed to do that. See clause 1 (c): > > > > http://msdn.microsoft.com/msdn-files/027/001/516/eula_mit.htm > Minor note: 1) The above link is now gone... 2) The above EULA was examined very closely by various communications manufactures. If the wording remains the same when the library gets out of BETA there may be some interesting counter EULAs. > Slight oops on their part, but then that license is fairly new. I don't > think it is aimed at the Linux world though. Microsoft are trying to prevent > something else - and its all about lock in again. > > If they prohibit people from linking free software with their own libraries > it allows them to prevent cost effective applications becoming available on > their platform so they can continue to inflate their prices. In paticular > I suspect this is aimed much more at things like OpenOffice, MySql on Windows, > Mozilla and friends. > > Of course in two years time no doubt "in the customers interest" it will be > Microsoft approved developers only , and a while after that nobody else will > be allowed to make apps for their product. > > 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/ - 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?
On Fri, 22 Jun 2001, D. Stimits wrote:
> 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
Ok, this is the linker for compilation time, it
is not related to the loader for shared libraries. You can even remove
/usr/bin/ld, and the system will run anyway binaries, but you will not be
able to link compiled objects.
try a find for the directory ldscripts or for those files,
elf_i386.xelf_i386.xs i386coff.xn i386linux.xbn
elf_i386.xbn elf_i386.xu i386coff.xr i386linux.xn
elf_i386.xn i386coff.xi386coff.xu i386linux.xr
elf_i386.xr i386coff.xbn i386linux.x i386linux.xu
you could not find the *coff* ones
those are the configuration file (unproper definition, i ask
excuse for my english), for /usr/bin/ld you are running
doing ld --version.
>
> 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/
name could be different, just could you e-mail the output for
the command tree inside of /usr?
>
> 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.
this is another thing...
> 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.
and then they compiled ALL other binaries from scratch with new linker,
passing /lib/i686/libc.so.6 explivitally, or changing the script
/usr/lib/libc.so?
boh! I do not know, and I am not thinking I am going to install a Red Hat
right now (simply it is not suitable for my needs, it is a great
distribution, of course, but it is not what my users need).
want my suggestion?
upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
them from sources against 2.4.X kernel includes. And you wil see if it
works how you would expect.
Luigi
-
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: plain 2.2.X: no ide CD-RW?
HI all,
> For a while now, I've been running a 2.4 kernel, but (for my research)
> I need to now run a 2.2 kernel. I was hoping to just run a stock
> 2.2.19, but I've found that I can't use my CD-RW drive, either as a
> plain IDE cdrom, or as a scsi-emulated one. (I have ide-scsi, ide-cd,
> and scsi all as modules.)
>
> When I try things as scsi-emulated CD-ROM, I get the following:
>
> Jun 22 19:58:15 lydia kernel: ide-scsi: The scsi wants to send us
> more data than expected - discarding data
> Jun 22 19:58:16 lydia last message repeated 83 times
> Instead, if I try ide-cd, I get these messages:
>
> Jun 22 20:11:38 lydia kernel: hdc: status error: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Jun 22 20:11:38 lydia kernel: hdc: drive not ready for command
> Jun 22 20:11:38 lydia kernel: hdc: status timeout: status=0xd0 { Busy }
> Jun 22 20:11:38 lydia kernel: hdc: DMA disabled
> Jun 22 20:11:38 lydia kernel: hdc: drive not ready for command
> Jun 22 20:11:38 lydia kernel: hdc: ATAPI reset complete
> Jun 22 20:11:48 lydia kernel: hdc: irq timeout: status=0x80 { Busy }
> Jun 22 20:11:48 lydia kernel: hdc: ATAPI reset complete
> Jun 22 20:11:59 lydia kernel: hdc: irq timeout: status=0x80 { Busy }
> Jun 22 20:11:59 lydia kernel: end_request: I/O error, dev 16:00
> (hdc), sector 64
> Jun 22 20:11:59 lydia kernel: hdc: status timeout: status=0x80 { Busy }
> Jun 22 20:11:59 lydia kernel: hdc: drive not ready for command
>
> I have these problems with 2.2.1[7-9] & 2.2.20pre5. However, if I add
> one of the IDE patches, all is well. 2.4 kernels have never given me
> these sorts of problems.
>
> I have a 440LX motherboard (HP Pavilion 8260), hooked up to a Plextor
> PX-W8432T 4/8/32 CD-RW, attached as /dev/hdc. I also have an OnStream
> DI-30 as /dev/hdd, and a Maxtor 91020D6 10G drive as /dev/hda.
>
> I can live with just running an ide-patched kernel, but it seems very
> odd that I can't even use the drive as an IDE CD-ROM drive with a
> stock 2.2 kernel. Is this a bug, or a limitation? I'd be happy to
> perform any tests to try and track this problem down.
Same here Anil,
w/ k2.4.4/2.4.5 in a dual p3 550 ( Intel 440BX ), CREATIVE CD-RW RW8432E (IDE).
< insmod ide-scsi / sr_mod >
ide-scsi: (IO,CoD) != (0,1) while issuing a packet command
hdb: DMA disabled
hdb: ATAPI reset complete
ide-scsi: The scsi wants to send us more data than expected - discarding data
ide-scsi: transferred 256 of 352 bytes
Vendor: CREATIVE Model: CD-RW RW8432E Rev: 1.05
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
ide-scsi: The scsi wants to send us more data than expected - discarding data
ide-scsi: transferred 64 of 82 bytes
ide-scsi: The scsi wants to send us more data than expected - discarding data
ide-scsi: transferred 132 of 158 bytes
sr0: scsi3-mmc drive: 264x/359x writer cd/rw xa/form2 cdda cartridge changer
ide-scsi: The scsi wants to send us more data than expected - discarding data
ide-scsi: transferred 64 of 82 bytes
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
MSDOS: Hardware sector size is 2048
fatfs: bogus cluster size
VFS: Can't find a valid MSDOS filesystem on dev 0b:00.
MSDOS: Hardware sector size is 2048
fatfs: bogus cluster size
VFS: Can't find a valid MSDOS filesystem on dev 0b:00.
cya;
> --Anil
>
> - --
> Anil Somayaji ([EMAIL PROTECTED])
> http://www.cs.unm.edu/~soma
> +1 505 872 3150
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
>
> iEYEARECAAYFAjs0SFkACgkQXOpXEmNZ3SeAtgCeL8j+ZvfANCB0acV6kL6AQFtB
> GdUAnidlfYrkv1o+hSlO4kNoWUNXw43v
> =RqEF
> -END PGP SIGNATURE-
> -
> 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/
--
_
Carlos E Gorges
([EMAIL PROTECTED])
Tech informática LTDA
Brazil
_
-
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: RPC vs Socket
> " " == Jan Hudec <[EMAIL PROTECTED]> writes: > Both seem to have pros and cons. RPC should be easier to write > (especialy the server side), but it performs bad with UDP on > slow links. (NFS did not work on 115200 serial line because of > too many dropped packets - TCP flow control too badly needed in > such cases). Or can linux do RPC over TCP? The RPC client code for TCP is ready and already working both in 2.2.18+ and 2.4.x. The server code however needs work. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
On Sat, Jun 23, 2001 at 04:54:20PM +0200, Der Herr Hofrat wrote:
> struct { short x; long y; short z; }bad_struct;
> struct { long y; short x; short z; }good_struct;
>
> I would expect both structs to be 8byte in size , or atleast the same size !
> but good_struct turns out to be 8bytes and bad_struct 12 .
>
> what am I doing wrong here ?
You're expecting the compiler to lay them out without any spacing between
them. There is no such requirement in C.
The compiler knows that its more efficient for long words to be accessed
on a long word boundary, so it wastes two bytes after each short in your
bad_struct case. However, it won't waste them in this case, because there
isn't a long:
struct { short x; short y; short z; }
If you really really really want that layout, then use
__attribute__((packed)) (read the gcc info files to find out what this
does), but don't unless you absolutely must.
Here is another struct layout example:
struct foo {
short x;
char y; /* implicit 1 byte padding after this element */
short z;
};
Again, the 1 byte padding can be removed by use of the __attribute__
above.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add kmalloc checking to fs/jffs/intrep.c (245-ac16)
[EMAIL PROTECTED] said: > The following patch adds some checks for kmalloc returning NULL to fs/ > jffs/intrep.c along with some way of getting that propagated back. > Applies against 245ac16 and 246p5. These dereferences were reported by > the Stanford team a way back. Fixed in my tree at about the same time the FTL code was, a month or so ago, along with some more important bugs. I haven't yet got round to feeding the updates to Linus - that's next on my list after the MTD stuff which is in 2.4.6. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sizeof problem in kernel modules
Hi !
can someone explain to me whats happening here ?
--simple.c--
#include
#include
struct { short x; long y; short z; }bad_struct;
struct { long y; short x; short z; }good_struct;
int init_module(void){
printk("good_struct %d, bad_struct
%d\n",sizeof(good_struct),sizeof(bad_struct));
return 0;
}
void cleanup_module(void){
}
--Makefile--
all: simple.o
CC= gcc
CFLAGS= -pipe -fno-strength-reduce -DCPU=686 -march=i686 \
-Wall -Wstrict-prototypes -g -D__KERNEL__ -DMODULE \
-D_LOOSE_KERNEL_NAMES -O2 -c
INCLUDE= -I/usr/include/linux
clean:
rm -f simple.o
---
I would expect both structs to be 8byte in size , or atleast the same size !
but good_struct turns out to be 8bytes and bad_struct 12 .
what am I doing wrong here ?
thx !
hofrat
-
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] add kmalloc checking to fs/jffs/intrep.c (245-ac16)
Hi.
The following patch adds some checks for kmalloc returning NULL
to fs/jffs/intrep.c along with some way of getting that propagated
back. Applies against 245ac16 and 246p5. These dereferences were
reported by the Stanford team a way back.
--- linux-245-ac16-clean/fs/jffs/intrep.c Thu Jun 21 21:26:24 2001
+++ linux-245-ac16/fs/jffs/intrep.c Sat Jun 23 16:25:33 2001
@@ -320,8 +320,8 @@
}
-__u32
-jffs_checksum_flash(struct mtd_info *mtd, loff_t start, int size)
+int
+jffs_checksum_flash(struct mtd_info *mtd, loff_t start, int size, __u32* checksum)
{
__u32 sum = 0;
loff_t ptr = start;
@@ -330,6 +330,10 @@
/* Allocate read buffer */
read_buf = (__u8 *) kmalloc (sizeof(__u8) * 4096, GFP_KERNEL);
+ if (!read_buf) {
+ printk(KERN_ERR "(jffs:) Out of memory allocating buffer. Aborting.");
+ return -1;
+ }
/* Loop until checksum done */
while (size) {
@@ -357,7 +361,8 @@
/* Return result */
D3(printk("checksum result: 0x%08x\n", sum));
- return sum;
+ *checksum = sum;
+ return 0;
}
static __inline__ void jffs_fm_write_lock(struct jffs_fmcontrol *fmc)
{
@@ -605,6 +610,8 @@
/* Allocate read buffer */
read_buf = (__u8 *) kmalloc (sizeof(__u8) * 4096, GFP_KERNEL);
+ if (!read_buf)
+ return -ENOMEM;
/* Start the scan. */
while (pos < end) {
@@ -859,7 +866,10 @@
if (raw_inode.rename) {
deleted_file = flash_read_u32(fmc->mtd, pos);
}
- checksum = jffs_checksum_flash(fmc->mtd, pos, raw_inode.dsize);
+ if (jffs_checksum_flash(fmc->mtd, pos,
+ raw_inode.dsize, &checksum))
+ return -ENOMEM;
+
pos += raw_inode.dsize
+ JFFS_GET_PAD_BYTES(raw_inode.dsize);
--
Regards,
Rasmus([EMAIL PROTECTED])
Television is called a medium because it is neither rare nor well-done.
-- Anonymous
-
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/
pci_fixup_via691_2 Holy Crusade
- I am 2.4.2-ac21 and I will destroy all your divx!!! - said little egg
- How can you destroy my divx, if you are just a minor kernel version...? - I
asked, it was first time in my life I talked to egg
- You will see!!! - said egg and disappear
>From this time - every day was sad. Whenever I run aviplay or mplayer - it
works slowly, and all movies were just a slideshow. I also asked x11perf what
it thinking about it - and it said: "your video is slow".
So I took my diff, gcc and sword and started to fight. After few hours I found
little monster, called pci_fixup_via691_2. I cut it with my sword, called Holy
Vim - and my kernel runs fast again!
So I wrote here about it. It was a good move, becouse next day I found in my
mailbox a Letter From God. It was short, but shine, so my dark room become
bright. The God, also known as Alan Cox said: "I will remove this bogus code,
and your life will be happy again". I heard singing of angels when I was
reading it. Then it was 2.4.4-ac2, I looked at it and I knew, that it was good.
But, the Evil can't be defeated so easly. I was just sleeping when 2.4.5
appeared. Then today I decided to check 2.4.6-pre5 and I scared when I heard
the same laught:
- I am here! I am still here!!! you can't kill me, couse I am internal part of
that kernel! hahahahaaha...!!!
So, it is The Holy Crusade. If you see:
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C598_1,
pci_fixup_via691_2 },
remember - it's an Evil Line From Hell. If you have VIA MVP3 (like me) you must
taste its blood every time you compile new _stable_ kernel. Remember about it.
Good Night!
-
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: RPC vs Socket
> I am in the way of building a new remote file system. > Presently I decided to use sockets for remote communication. Lately I > understood that RPC is used in coda and nfs file systems(is it so). I want to > know the fessibility in using RPC in the new file system. Both seem to have pros and cons. RPC should be easier to write (especialy the server side), but it performs bad with UDP on slow links. (NFS did not work on 115200 serial line because of too many dropped packets - TCP flow control too badly needed in such cases). Or can linux do RPC over TCP? For puropose of shool excercise the work saved with RPC might be tha main argument. - Jan Hudec `Bulb' <[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: How does ramfs actually fills the page cache with data?
On Fri, Jun 22, 2001 at 05:45:27PM -0400, Ho Chak Hung wrote:
> 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?
The page cache does it itself.
"readpage" is to move pages from the backing store into the page
cache.
"writepage" and friends is for updating the backing store with
the contents of the page cache.
There is no real backing store of ramfs, since ramfs data lives
completly in page cache.
But we cannot give the user random memory contents, so we zero it
out on readpage and prepare_write.
The data is copied with copy_{from,to}_user in the generic file
operations (look how ramfs_file_operations is defined and look at
the functions referenced), which read/write through page cache.
Regards
Ingo Oeser
--
Use ReiserFS to get a faster fsck and Ext2 to fsck slowly and gently.
-
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] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
Hi.
The patch below adds a kmalloc check to drivers/pcmcmia/rsrc_mgr.c.
Against 245-ac16 but aplies to 256p6 also. Reported a while back
by the stanford team.
--- linux-245-ac16-clean/drivers/pcmcia/rsrc_mgr.c Sat May 19 20:59:21 2001
+++ linux-245-ac16/drivers/pcmcia/rsrc_mgr.cSat Jun 23 15:06:54 2001
@@ -189,6 +189,11 @@
/* First, what does a floating port look like? */
b = kmalloc(256, GFP_KERNEL);
+if (!b) {
+ printk(" -- aborting.\n");
+ printk(KERN_ERR "Out of memory.");
+ return;
+}
memset(b, 0, 256);
for (i = base, most = 0; i < base+num; i += 8) {
if (check_io_resource(i, 8))
--
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: osst & ide-2.2.19 conflict?
"Anil B. Somayaji" wrote:
>
> In the ide.2.2.19.05042001 patch, there is the following bit of code
> in ide-scsi.c, which prevents the ide-scsi driver from allowing access
> to an OnStream DI-30 tape drive. This is strange, since this same
> drive can be used with the included ide-scsi + osst drivers in the
> stock 2.2.19 kernel. If you delete this bit, however, ide-scsi
> recognizes the drive, and the osst driver seems to work fine.
>
> Here's the offending code:
>
> #ifndef CONFIG_BLK_DEV_IDETAPE
>/*
> * The Onstream DI-30 does not handle clean emulation, yet.
> */
>if (strstr(drive->id->model, "OnStream DI-30")) {
>printk("ide-tape: ide-scsi emulation is not supported for %s.\n",
>drive->id->model);
>continue;
>}
> #endif /* CONFIG_BLK_DEV_IDETAPE */
>
> Any reason for this to stay in the ide patch, or is it now obsolete?
>
It is obsolete, and can safely be removed.
Success. Willem Riede.
-
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/
Shared memory quantity not being reflected by /proc/meminfo
Since the 2.4.x advent of shm as tmpfs or thereabouts, /proc/meminfo shows shared memory as 0. It is in reality not zero, and is being allocated, and shows up in /proc/sysvipc/shm and /proc/sys/kernel/shmall etc.. Neither 2.4.6-pre5 nor 2.4.5-ac17 have the correct display. - 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/
Some new problems with 2.4.5
(I'm resending this, it looks like it was lost somewhere ... and there is some more mem info...) Hello, I have a machine that's dual coppermine/927 (that's what /proc/cpuinfo say:) ), with 1.2G ram, Dell PercRaid, 3com 3c905B NIC. I'm using kernel 2.4.5 with the percraid patches. The problem with the machine is, that it works for some time, and then it goes to hell. I spoke with Rik van Riel last night, and he asked me to get some info from /proc/meminfo around the crash. I've appended it here, and the kernel log messages ( recovered from remote logging station, the machine was unsuble and was rebooted through the power switch :) ) . It doesn't look like the other problems reported with 2.4 VM, so I still haven't tried to use 2.4.6pre3, because it's production machine, and I'd like to stuck with something that's not prerelease :) ( full log is avialable at http://www.ludost.net/eru/ - meminfo.log.bz2, the kernel log from the 'crash' moment, and the dmesg of the machine). (the log was created with while /bin/true; cat /proc/meminfo >> dumpfile;sleep 20; done ). meminfo.log , last lines: total:used:free: shared: buffers: cached: Mem: 1317535744 1308397568 91381760 190033920 919121920 Swap: 2657390592 25657344 2631733248 MemTotal: 1286656 kB MemFree: 8924 kB MemShared: 0 kB Buffers:185580 kB Cached: 897580 kB Active: 973212 kB Inact_dirty:107736 kB Inact_clean: 2228 kB Inact_target: 744 kB HighTotal: 393208 kB HighFree: 2036 kB LowTotal: 893448 kB LowFree: 6888 kB SwapTotal: 2595108 kB SwapFree: 2570052 kB total:used:free: shared: buffers: cached: Mem: 1317535744 1312010240 55255040 184389632 927334400 Swap: 2657390592 25657344 2631733248 MemTotal: 1286656 kB MemFree: 5396 kB MemShared: 0 kB Buffers:180068 kB Cached: 905600 kB Active: 980272 kB Inact_dirty:103148 kB Inact_clean: 2248 kB Inact_target: 748 kB HighTotal: 393208 kB HighFree: 2036 kB LowTotal: 893448 kB LowFree: 3360 kB SwapTotal: 2595108 kB SwapFree: 2570052 kB total:used:free: shared: buffers: cached: Mem: 1317535744 1312051200 54845440 175587328 936456192 Swap: 2657390592 25657344 2631733248 MemTotal: 1286656 kB MemFree: 5356 kB MemShared: 0 kB Buffers:171472 kB Cached: 914508 kB Active: 985180 kB Inact_dirty: 98440 kB Inact_clean: 2368 kB Inact_target: 712 kB HighTotal: 393208 kB HighFree: 2036 kB LowTotal: 893448 kB LowFree: 3320 kB SwapTotal: 2595108 kB SwapFree: 2570052 kB total:used:free: shared: buffers: cached: Mem: 1317535744 1312182272 53534720 167284736 943894528 Swap: 2657390592 25657344 2631733248 MemTotal: 1286656 kB MemFree: 5228 kB MemShared: 0 kB Buffers:163364 kB Cached: 921772 kB Active: 988760 kB Inact_dirty: 93888 kB Inact_clean: 2488 kB Inact_target: 772 kB HighTotal: 393208 kB HighFree: 2036 kB LowTotal: 893448 kB LowFree: 3192 kB SwapTotal: 2595108 kB SwapFree: 2570052 kB kern.log , last lines : Jun 23 08:17:41 eru kernel: possible SYN flooding on port 80. Sending cookies. Jun 23 08:17:41 eru kernel: __alloc_pages: 1-order allocation failed. Jun 23 08:18:41 eru last message repeated 3201 times Jun 23 08:18:41 eru kernel: possible SYN flooding on port 80. Sending cookies. Jun 23 08:18:41 eru kernel: __alloc_pages: 1-order allocation failed. Jun 23 08:19:41 eru last message repeated 3191 times Jun 23 08:19:41 eru kernel: possible SYN flooding on port 80. Sending cookies. Jun 23 08:19:41 eru kernel: __alloc_pages: 1-order allocation failed. Jun 23 08:20:41 eru kernel: possible SYN flooding on port 80. Sending cookies. Jun 23 08:20:41 eru last message repeated 3354 times Jun 23 08:20:42 eru kernel: __alloc_pages: 1-order allocation failed. And, meminfo from the last crash ( happened 30 mins ago ) : total:used:free: shared: buffers: cached: Mem: 1317535744 1310912512 66232320 142184448 897589248 Swap: 2657390592 2813952 2654576640 MemTotal: 1286656 kB MemFree: 6468 kB MemShared: 0 kB Buffers:138852 kB Cached: 876552 kB Active: 765348 kB Inact_dirty:248260 kB Inact_clean: 1796 kB Inact_target: 300 kB HighTotal: 393208 kB HighFree: 2036 kB LowTotal: 893448 kB LowFree: 4432 kB SwapTotal: 2595108 kB SwapFree: 2592360 kB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.20-pre, parport_probe, output truncated
Hi,
When I load the 'lp' module, I got the following
[jean-luct@debian-f5ibh] ~ # modprobe lp
parport0: PC-style at 0x378 (0x778), irq 7 [SPP,ECP,ECPEPP,ECPPS2]
parport0: Unspecified, EPSON Styl
lp0: using parport0 (interrupt-driven).
After increasing the 'giveup' delay in parport_probe.c, I've the correct
output :
[jean-luct@debian-f5ibh] ~ # modprobe lp
parport0: PC-style at 0x378 (0x778), irq 7 [SPP,ECP,ECPEPP,ECPPS2]
parport0: Printer, EPSON Stylus COLOR 500
lp0: using parport0 (interrupt-driven).
--- parport_probe.old Sat Jun 23 10:01:57 2001
+++ parport_probe.c Sat Jun 23 13:16:48 2001
@@ -55,7 +55,7 @@
unsigned int count = 0;
unsigned char z=0;
unsigned char Byte=0;
- unsigned long igiveupat=jiffies+5*HZ;
+ unsigned long igiveupat=jiffies+9*HZ;
for (i=0; time_before(jiffies, igiveupat); i++) {
/* if(current->need_resched) schedule(); */
Regards
Jean-Luc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel BUG in inode.c line 486 in 2.4.5
I should mention, there are also NFS3 mounts on the system.. Dylan Griffiths wrote: > -=- > > kernel BUG at inode.c:486! > invalid operand: > CPU:0 > EIP:0010:[] > EFLAGS: 00013286 > eax: 001b ebx: c726a2c0 ecx: 0001 edx: c022a068 > esi: c022cee0 edi: d489c9c0 ebp: d501dfa4 esp: d501deec > ds: 0018 es: 0018 ss: 0018 > Process gmc (pid: 169, stackpage=d501d000) > Stack: c01f602c c01f608b 01e6 c726a2c0 c0142887 c726a2c0 d4221a40 > c726a2c0 >c015a66d c726a2c0 c01402f6 d4221a40 c726a2c0 d4221a40 > c0138d18 >d4221a40 d501df68 c013945a d489c9c0 d501df68 cc51b000 > > Call Trace: [] [] [] [] [] > [] [] >[] > > Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 > -- 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/
Kernel BUG in inode.c line 486 in 2.4.5
Found these lurking in dmesg.. no timestamp on them, so I have no idea when they happened.. the system seems ok, but I'm going to go fsck it a bit now.. Asus A7M266 board (VIA Southbridge). VIA82CXXX chipset support is on, use DMA by default is on. ext2 partitions on a 20gb drive: FilesystemSize Used Avail Use% Mounted on /dev/hda5 2.9G 1.9G 873M 69% / /dev/hda7 13G 10G 2.6G 80% /home tmpfs 103M 0 103M 0% /var/shm Hope this helps.. -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00013286 eax: 001b ebx: c726a2c0 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: d501dfa4 esp: d501deec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 169, stackpage=d501d000) Stack: c01f602c c01f608b 01e6 c726a2c0 c0142887 c726a2c0 d4221a40 c726a2c0 c015a66d c726a2c0 c01402f6 d4221a40 c726a2c0 d4221a40 c0138d18 d4221a40 d501df68 c013945a d489c9c0 d501df68 cc51b000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: c6bab980 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: d5559fa4 esp: d5559eec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 18464, stackpage=d5559000) Stack: c01f602c c01f608b 01e6 c6bab980 c0142887 c6bab980 d4221dc0 c6bab980 c015a66d c6bab980 c01402f6 d4221dc0 c6bab980 d4221dc0 c0138d18 d4221dc0 d5559f68 c013945a d489c9c0 d5559f68 cae3b000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: cf9b4640 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: c3bd1fa4 esp: c3bd1eec ds: 0018 es: 0018 ss: 0018 Process gmc (pid: 18470, stackpage=c3bd1000) Stack: c01f602c c01f608b 01e6 cf9b4640 c0142887 cf9b4640 c1c1b5c0 cf9b4640 c015a66d cf9b4640 c01402f6 c1c1b5c0 cf9b4640 c1c1b5c0 c0138d18 c1c1b5c0 c3bd1f68 c013945a d489c9c0 c3bd1f68 c6087000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -=- kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: cf9b4040 ecx: 0001 edx: c022a068 esi: c022cee0 edi: d489c9c0 ebp: d4ea1fa4 esp: d4ea1eec ds: 0018 es: 0018 ss: 0018 Process xmms (pid: 14150, stackpage=d4ea1000) Stack: c01f602c c01f608b 01e6 cf9b4040 c0142887 cf9b4040 c1c1b9c0 cf9b4040 c015a66d cf9b4040 c01402f6 c1c1b9c0 cf9b4040 c1c1b9c0 c0138d18 c1c1b9c0 d4ea1f68 c013945a d489c9c0 d4ea1f68 d3693000 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68 -- 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/
Re: Annoying kernel behaviour
In clouddancer.list.kernel, you wrote: > > 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). Look in the people/mingo directory for a patch > 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: I have: Linux video capture interface: v1.00 bttv: driver version 0.7.63 loaded bttv: using 2 buffers with 2080k (4160k total) for capture bttv: Host bridge needs ETBF enabled. bttv: Bt8xx card found (0). bttv0: Bt878 (rev 2) at 00:0b.0, irq: 10, latency: 32, memory: 0xe300 bttv0: subsystem: 144f:3000 => TView 99 (CPH063) => card=38 bttv0: model: BT878(TView99 CPH063) [autodetected] bttv0: enabling ETBF (430FX/VP3 compatibilty) i2c-core.o: adapter bt848 #0 registered as adapter 0. working in 2.4.5-ac12 SMP+RAID. I used Bttv-0.7.63-2.4.3.patch.bz2 from the website. Video4linux has always worked in the various 2.4 kernels I've tried. >and accesing mod_video, the box locked up hard (not even sysrq worked). And I don't run mod_video, but xawtv works fine. Did you try that or rebuilding mod_video? >when I rebooted, I found that some files is /etc were eaten -- even though You must have grues. -- "Or heck, let's just make the VM a _real_ Neural Network, that self trains itself to the load you put on the system. Hideously complex and evil? Well, why not wire up that roach on the floor, eating that stale cheese doodle. It can't do any worse job on VM that some of the VM patches I've seen..." -- Jason McMullan ditto - 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 or Advanced power ...
> I agree ACPI sucks, but I have a SMP box that I need to be able to > powerdown remotely. Is there any reason APM can't do that? I mean, I > understand APM was never meant for SMP, but... ? You can tell 2.4 to do APM poweroffs on SMP boxes. It works for most BIOSes - 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 :-(((
> 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. By all means. I doubt I can help much on that issue but I can at least think about it > Could these discussions be opened up to a wider readership? Perhaps you > could use [EMAIL PROTECTED], or > [EMAIL PROTECTED]? I have enough mail without reading those lists too. All I am talking about here is parsing the irq routing and apic tables. - 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/
plain 2.2.X: no ide CD-RW?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For a while now, I've been running a 2.4 kernel, but (for my research)
I need to now run a 2.2 kernel. I was hoping to just run a stock
2.2.19, but I've found that I can't use my CD-RW drive, either as a
plain IDE cdrom, or as a scsi-emulated one. (I have ide-scsi, ide-cd,
and scsi all as modules.)
When I try things as scsi-emulated CD-ROM, I get the following:
Jun 22 19:58:15 lydia kernel: ide-scsi: The scsi wants to send us
more data than expected - discarding data
Jun 22 19:58:16 lydia last message repeated 83 times
Instead, if I try ide-cd, I get these messages:
Jun 22 20:11:38 lydia kernel: hdc: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Jun 22 20:11:38 lydia kernel: hdc: drive not ready for command
Jun 22 20:11:38 lydia kernel: hdc: status timeout: status=0xd0 { Busy }
Jun 22 20:11:38 lydia kernel: hdc: DMA disabled
Jun 22 20:11:38 lydia kernel: hdc: drive not ready for command
Jun 22 20:11:38 lydia kernel: hdc: ATAPI reset complete
Jun 22 20:11:48 lydia kernel: hdc: irq timeout: status=0x80 { Busy }
Jun 22 20:11:48 lydia kernel: hdc: ATAPI reset complete
Jun 22 20:11:59 lydia kernel: hdc: irq timeout: status=0x80 { Busy }
Jun 22 20:11:59 lydia kernel: end_request: I/O error, dev 16:00
(hdc), sector 64
Jun 22 20:11:59 lydia kernel: hdc: status timeout: status=0x80 { Busy }
Jun 22 20:11:59 lydia kernel: hdc: drive not ready for command
I have these problems with 2.2.1[7-9] & 2.2.20pre5. However, if I add
one of the IDE patches, all is well. 2.4 kernels have never given me
these sorts of problems.
I have a 440LX motherboard (HP Pavilion 8260), hooked up to a Plextor
PX-W8432T 4/8/32 CD-RW, attached as /dev/hdc. I also have an OnStream
DI-30 as /dev/hdd, and a Maxtor 91020D6 10G drive as /dev/hda.
I can live with just running an ide-patched kernel, but it seems very
odd that I can't even use the drive as an IDE CD-ROM drive with a
stock 2.2 kernel. Is this a bug, or a limitation? I'd be happy to
perform any tests to try and track this problem down.
Thanks!
--Anil
- --
Anil Somayaji ([EMAIL PROTECTED])
http://www.cs.unm.edu/~soma
+1 505 872 3150
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iEYEARECAAYFAjs0SFkACgkQXOpXEmNZ3SeAtgCeL8j+ZvfANCB0acV6kL6AQFtB
GdUAnidlfYrkv1o+hSlO4kNoWUNXw43v
=RqEF
-END PGP SIGNATURE-
-
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: [OT]Re: One more ZDNet article with BillG hammering Linux andOpen Source.
On 22 Jun 2001, Miles Lane wrote: > It would be great to see the "Shared Source" licenses that Microsoft has > made people sign. It would be especially interesting to compare the It would be great to see you learning WTF "offtopic" means and taking the advocacy crap to the places where it belongs. - 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/
osst & ide-2.2.19 conflict?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In the ide.2.2.19.05042001 patch, there is the following bit of code
in ide-scsi.c, which prevents the ide-scsi driver from allowing access
to an OnStream DI-30 tape drive. This is strange, since this same
drive can be used with the included ide-scsi + osst drivers in the
stock 2.2.19 kernel. If you delete this bit, however, ide-scsi
recognizes the drive, and the osst driver seems to work fine.
Here's the offending code:
#ifndef CONFIG_BLK_DEV_IDETAPE
/*
* The Onstream DI-30 does not handle clean emulation, yet.
*/
if (strstr(drive->id->model, "OnStream DI-30")) {
printk("ide-tape: ide-scsi emulation is not supported for %s.\n",
drive->id->model);
continue;
}
#endif /* CONFIG_BLK_DEV_IDETAPE */
Any reason for this to stay in the ide patch, or is it now obsolete?
--Anil
- --
Anil Somayaji ([EMAIL PROTECTED])
http://www.cs.unm.edu/~soma
+1 505 872 3150
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iEYEARECAAYFAjs0Q/UACgkQXOpXEmNZ3SfrogCfbNzSB7zOjkItzYTOoplxaJJt
5AYAnRrB+KGTYj7wf3/GeV92TLvpKGqi
=1TVG
-END PGP SIGNATURE-
-
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/
