* Re: SCSI host numbers?
From: Itai Nahshon @ 2002-01-15 12:19 UTC (permalink / raw)
To: Richard Gooch; +Cc: Alan Cox, linux-kernel
In-Reply-To: <200201140636.g0E6a4b16527@vindaloo.ras.ucalgary.ca>
On Monday 14 January 2002 08:36 am, Richard Gooch wrote:
> So how about in scsi_host_no_init() we call alloc_unique_number() N
> times until we've allocated the required number of host numbers for
> manual control. These will never be freed. Then all other host
> allocations can be done dynamically. We would just need a flag in the
> host structure to disable deallocation of the number if it's one of
> the reserved numbers.
See that dynamic hosts are also added to the list and *never* removed
from it (even when the host is unregistered). With that behaviour your
unique number functions would be an overkill because we must never
free host nubers.
I suggest these changes:
max_scsi_host initialized in scsi_host_no_init.
max_scsi_host never decremented.
That would fix the problem that I reported.
Than (cosmetic):
rename next_scsi_host to count_scsi_hosts (or num_scsi_hosts)
because it actually just counts the number of registered scsi hosts.
The current name for that variable is confusing...
-- Itai
^ permalink raw reply
* Re: [PATCH] O_DIRECT with hardware blocksize alignment
From: Andrea Arcangeli @ 2002-01-15 12:20 UTC (permalink / raw)
To: Joel Becker, Marcelo Tosatti, lkml
In-Reply-To: <20020115032126.F1929@parcelfarce.linux.theplanet.co.uk>
On Tue, Jan 15, 2002 at 03:21:26AM +0000, Joel Becker wrote:
> On Sat, Jan 12, 2002 at 01:31:22PM +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 09, 2002 at 07:56:07PM +0000, Joel Becker wrote:
> > > min(I/O alignment, s_blocksize) is used as the effective
> > > blocksize. eg:
> > >
> > > I/O alignment s_blocksize final blocksize
> > > 8192 4096 4096
> > > 4096 4096 4096
> > > 512 4096 512
> >
> > this falls in the same risky category of the vary-I/O patch from Badari
> > (check the discussion on l-k) for rawio, so to make it safe it also will
>
> How so? All I/O is at the computed blocksize. In every
> request, the size of each I/O in the kiovec is the same. The
in the kiovec yes, but in the same request queue there will be also the
concurrent requests from the filesystem, and they will have different
b_size, see Jens's mail about different b_size merged in the same
request.
actually we could also forbid merging at the ll_rw_block layer if b_size
is not equal, maybe that's the simpler solution to that problem after
all, merging between kiovec I/O and buffered I/O probably doesn't
matter.
> computation is done upon entrance to generic_file_direct_IO, and it is
> kept that way. You don't have bh[0]->b_size = 512; bh[1]->b_size =
> 4096;
> Hmm, maybe you mean things like that rumoured 3-ware issue. I
> dunno. I do know that this code seems to work just fine with ide,
> aha7xxx, and the qlogic driver. Certain software really wants to use
> O_DIRECT, and they align I/O on 512byte boundaries. So any scheme that
> fails this when it doesn't have to is a problem.
>
> > aligned I/O, but still large I/O) So I suggest you to check Badari's
> > stuff and the thread on l-k and to make a new patch incremental with his
>
> I've added myself to that thread as well.
>
> Joel
>
> --
>
> "Vote early and vote often."
> - Al Capone
>
> http://www.jlbec.org/
> jlbec@evilplan.org
Andrea
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: Andi Kleen @ 2002-01-15 12:16 UTC (permalink / raw)
To: peter; +Cc: linux-kernel
In-Reply-To: <20020115025840.11509.qmail@science.horizon.com.suse.lists.linux.kernel>
peter@horizon.com writes:
> 1) The main kernel is contiguous in physical memory and is mapped with
> large (4 MB) pages. This reduces pressure on the TLB. Modules are
> loaded in vmalloc memory, which uses small pages, and therefore
> competes for TLB space. This is a performance penalty, especially
> as most current machines have undersized TLBs already. (A 64-entry
> TLB with 4K pages maps 256K at a time. On-chip L2 caches are this
> large or larger. Thus, as a crude approximation, every L2 miss also
> causes a TLB miss.)
-aa tries to load modules into the linear mapping when possible.
That usually works when you load the modules early when the memory
isn't that fragmented yet.
I agree on that trying to put everything into modules isn't a good idea,
especially because of your second point.
-Andi
^ permalink raw reply
* [BUG] symlink problem with knfsd and reiserfs
From: Trond Myklebust @ 2002-01-15 12:06 UTC (permalink / raw)
To: Neil Brown; +Cc: Hans-Peter Jansen, linux-kernel
In-Reply-To: <20020115115019.89B55143B@shrek.lisa.de>
>>>>> " " == Hans-Peter Jansen <hpj@urpla.net> writes:
> In syslog, this message appears: Jan 15 00:21:03 elfe kernel:
> nfs_refresh_inode: inode 50066 mode changed, 0100664 to 0120777
The error is basically telling you that ReiserFS filehandles are being
reused by the server. Doesn't Reiser provide a generation count to
guard against this sort of thing?
My 'fix' just solves the immediate problem of the wrong file mode. It
does not solve the problems of data corruption that can occur when the
client is incapable of distinguishing the 'old' and 'new' files that
share the same filehandle.
Cheers,
Trond
^ permalink raw reply
* Re: 8240 booting:bootp time out and hd lost interrupt
From: Neil Horman @ 2002-01-15 12:03 UTC (permalink / raw)
To: ×ÞÌÎ; +Cc: linuxppc-embedded@lists.linuxppc.org
In-Reply-To: <200201151021.EAA18816@lists.linuxppc.org>
Hello-
Not sure if these are going to be you're exact answers, but I've
recently tackled both problems on a custom MPC860P based board:
1)
> I mark the line i wish you pay attention to.i have two questions: one is >why the hdc lost the interrupt.
I had the same error when trying to build a 2.4.14 kernel to use
the 860 PCMCIA interface populated with a CompactFlash card as an ide
device. My problem was that I actaully had no interrupt connected to
the PCMCIA interface, so I naturally was loosing interrupts. My
solution (and this may not be perfect for you as you appear to have
multiple ide devices was to modify the ide_timer_expiry function so that
it simply called the appropriate interrupt handler, converting this
non-interruptable device into a polled device of sorts. In fact, there
should be a case in ide_timer_expiry that calls the interrupt handler in
the case that an interrupt got raised just as the timer was expiring. I
used that as my guideline. From there its just a matter of adjusting
the timer timeout value in in ide_set_handler such that you can get
decent performance out of it. Of course, this may well not be your
problem, but you may want to check, just in case.
2)
>the other is why the bootp time out. i test the host dhcp configuration with >win98 as client.
It looks to me as though you don't have your bootp server set up
properly. Looking at your tcpdump, I see you sending out bootp requests
(eth0 B 0.0.0.0 >....), but I see no responsees. The 192.168.10.13
address appears multiple times in your tcpdump prior to your bootp
requests being sent (even on the lo interface which is odd), so it looks
like that may be a configuration error (perhaps something you passed in
on the kernel command line?). The fact that you can boot a Win98 client
with your DHCP server just means that it serves DHCP requests well,
which are close to, but not bootp requests. I use the ISC DHCP server
here under red hat 7.1, and to use it to serve bootp requires that I add
a special bootp entry for every address I wish to serve, like this:
host <name>:
{
hardware ethernet <MAC>;
fixed address <IP>;
};
Hope that helps!
Neil Horman
×ÞÌÎ wrote:
>
> Hello:
> I'm a newer to PowerPC. when i port linux to PowerPC 8240,i met some problem.anyone give me advices will be appreciate.
> i use board sandpoint 3, the cpu board is mpc8240.
> I mark the line i wish you pay attention to.i have two questions: one is why the hdc lost the interrupt. the other is why the bootp time out. i test the host dhcp configuration with win98 as client.
> The dip switch on cpu board is set to : sw2 01111,sw3 11011 (1 means ON)
> BTW,who could tell me every bit of the two dip switch mean? I couldn't find document about it.
> The dip switch on main board is set to: sw1 11111010 ,sw2 11111111.
> The type of main board is "ppceval-sp3 rev x3". the CPU board is
> "m98ppmc8240 rev x2" .linux kernel is Mvista Hard Hat Linux 2.0 for
> ppc 82xx. My hard disk type is "Quantum fireball 3.5series 30.0GB".
> the following is bootup message:
>
> DINK32_KAHLUA >>dl -k
> #>ascii-xfr -svn -l 10 vmlinuz-motolola-sandpoint.srec>/dev/ttyS0
> DINK32_KAHLUA >>go 900000
> loaded at: 00900000 009091B8
> relocated to: 00800000 008091B8
> zimage at: 00906000 00998F41
> avail ram: 00400000 00800000
>
> Linux/PPC load:
> Uncompressing Linux...done.
> Now booting the kernel
> Total memory = 32MB; using 0kB for hash table (at 00000000)
> Linux version 2.4.2_hhl20 (root@tony) (gcc version 2.95.3 20010315 (release/Mon1Motorola SPS Sandpoint Test Platform
> Sandpoint port (C) 2000, 2001 MontaVista Software, Inc. (source@mvista.com)
> On node 0 totalpages: 8192
> zone(0): 8192 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line:
> OpenPIC Version 1.2 (1 CPUs and 24 IRQ sources) at f7fd0000
> OpenPIC timer frequency is 100.000000 MHz
> time_init: decrementer frequency = 24.752286 MHz
> Calibrating delay loop... 131.89 BogoMIPS
> Memory: 30596k available (1048k kernel code, 440k data, 88k init, 0k highmem)
> Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
> Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
> POSIX conformance testing by UNIFIX
> PCI: Probing PCI hardware
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Starting kswapd v1.8
> pty: 256 Unix98 ptys configured
> block: queued sectors max/low 20256kB/6752kB, 64 slots per queue
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> W82C105: IDE controller on PCI bus 00 dev 59
> W82C105: chipset revision 5
> W82C105: 100% native mode on irq 17
> ide0: BM-DMA at 0xbfffd0-0xbfffd7, BIOS settings: hda:pio, hdb:pio
> SL82C105 command word: 5
> IDE timing: 00000909, resetting to PIO0 timing
> ide1: BM-DMA at 0xbfffd8-0xbfffdf, BIOS settings: hdc:pio, hdd:pio
> SL82C105 command word: 5
> IDE timing: 000003e4, resetting to PIO0 timing
> hdc: QUANTUM FIREBALLP AS30.0, ATA DISK drive
> ide1 at 0xbfffe8-0xbfffef,0xbfffe6 on irq 15
> hdc: 58633344 sectors (30020 MB) w/1902KiB Cache, CHS=58168/16/63
> /*******************************************************************************
> Partition check:
> hdc:hdc: lost interrupt
> hdc: lost interrupt
> hdc: lost interrupt
> hdc: lost interrupt
> hdc: lost interrupt
> [PTBL] [3649/255/63] hdc1 <hdc: lost interrupt
> hdc: lost interrupt
> hdc5hdc: lost interrupt
> hdc: lost interrupt
> hdc6 >
> *******************************************************************************/
> loop: loaded (max 8 devices)
> Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI endttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 2048)
> /*******************************************************************************
> Sending BOOTP requests.......<6>NETDEV WATCHDOG: eth0: transmit timed out
> ....<6>NETDEV WATCHDOG: eth0: transmit timed out .. timed out!
> ********************************************************************************/
> IP-Config: No network devices available.
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Root-NFS: No NFS server available, giving up.
> VFS: Unable to mount root fs via NFS, trying floppy.
> request_module[block-major-2]: Root fs not mounted
> VFS: Cannot open root device "" or 02:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 02:00
>
> and I use tcpdump to listen to the eth0, and receive something like that:
>
> 14:34:27.591370 eth0 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xc6c3f016 secs:88 [|bootp] (DF)
> 14:34:27.591925 eth0 > 192.168.10.13.bootps > 255.255.255.255.bootpc: xid:0xc6c3f016 secs:88 Y:192.168.10.100 S:192.168.10.13 ether 0:e0:4c:45:56:af [|bootp] (DF)
> 14:34:27.595609 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:28.591256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:29.591256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:30.591402 lo > 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:30.591402 lo < 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:32.601383 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:33.601256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:34.601256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:35.601276 lo > 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:35.601276 lo < 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:37.612096 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:38.611257 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:39.611257 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:40.611278 lo > 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:40.611278 lo < 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:42.621330 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:43.621256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:44.621256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:45.621277 lo > 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:45.621277 lo < 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:47.633769 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:48.631263 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:49.631256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:50.631277 lo > 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:50.631277 lo < 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:52.641343 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:53.641271 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:54.641268 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13 (0:e0:4c:3b:f6:ca)
> 14:34:55.641289 lo > 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:55.641289 lo < 192.168.10.13 > 192.168.10.13: icmp: host 192.168.10.1 unreachable [tos 0xc0]
> 14:34:55.711924 eth0 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xc6c3f016 secs:117 [|bootp] (DF)
> 14:34:55.712391 eth0 > 192.168.10.13.bootps > 255.255.255.255.bootpc: xid:0xc6c3f016 secs:117 Y:192.168.10.100 S:192.168.10.13 ether 0:e0:4c:45:56:af [|bootp] (DF)
> 14:35:25.712515 eth0 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xc6c3f016 secs:147 [|bootp] (DF)
> 14:35:25.713052 eth0 > 192.168.10.13.bootps > 255.255.255.255.bootpc: xid:0xc6c3f016 secs:147 Y:192.168.10.100 S:192.168.10.13 ether 0:e0:4c:45:56:af [|bootp] (DF)
>
> It seems that the host ack the target's require, but target did't accept . So the target has no right IP address.
>
> regards.
> stone
>
> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡stone@pocketix.com
> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-01-15
>
--
/***************************************
*Neil Horman
*Master of Software Feng Shui
*Lvl7 Systems
*(919)-865-2915
***************************************/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [RFC] klibc requirements
From: Felix von Leitner @ 2002-01-15 11:55 UTC (permalink / raw)
To: Albert D. Cahalan; +Cc: Greg KH, linux-kernel, andersen
In-Reply-To: <200201150308.g0F38rp502016@saturn.cs.uml.edu>
Thus spake Albert D. Cahalan (acahalan@cs.uml.edu):
> I think the dietlibc idea has to be scrapped so we can run BSD apps.
> (and others maybe, but I'm not looking to start a flame war)
What apps are you talking about?
> DNS is very good to have. There are many things one might want
> to specify by name. NFS servers, NIS servers, SMB servers, and
> even the machine itself to get an IP via DNS.
You don't need NIS or SMB before mounting the root disk.
If you want NFS to mount your root file system, you get the IP via DHCP
normally, so you don't need DNS. And you can't get your own IP via DNS
because you need to have an IP to use DNS.
> Even with ELF, you shouldn't need that 10 kB.
Please go ahead and implement it.
Fame and fortune await you! ;)
> Treat ELF like a.out, getting rid of the -fPIC stuff in favor of
> offsets assigned when you build the initramfs.
ELF is a standard.
You can't just go out and re-invent dynamic linking completely.
First and most importantly of all, the GNU toolchain support the ELF
standard, not my personal ELF dialect. I have no desire to write a
linker. I'm happy enough that I found Olaf who was willing to write an
ld.so (and I was close enough to hear all his ranting about how complex
ELF is).
> Dynamic linking should
> be:
> open
> mmap
> mmap
> close
> You know the file to open. You know what offset you need it at.
> There isn't any need for symbols. OK, that's half-dynamic,
> but it gets the job done.
Again, please do it. I know that it would be possible. But it would
not be standard and I don't think it's worth the effort. The most
important reason is that static linking produces small binaries with the
diet libc and uclibc. As long as your software does not destroy that by
having a few dozen mini binaries around, all linked against the same
monster do-it-all library, it works.
Felix
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: T. A. @ 2002-01-15 11:53 UTC (permalink / raw)
To: Linux Kernel Mailing List, esr
In-Reply-To: <20020114145035.E17522@thyrsus.com>
----- Original Message -----
From: "Eric S. Raymond" <esr@thyrsus.com>
To: <arjan@fenrus.demon.nl>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, January 14, 2002 2:50 PM
Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --
the elegant solution)
> arjan@fenrus.demon.nl <arjan@fenrus.demon.nl>:
> > Of course there are other settings that do have impact (CPU type mostly,
> > maybe memory layout) but other than that... distros already ship several
> > binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> > account for CPU type and amount etc.
>
> OK. Scenario #2:
>
> Tillie's nephew Melvin is a junior-grade geek. He's working his way
> through college doing website administration for small businesses. He
> doesn't know C, but he can hack his way around Perl and a little PHP,
> and he can type "configure; make". He's been known to wear a penguin
> T-shirt.
>>> SNIP <<<
> Autoconfigure saves the day. Possibly it even helps Melvin get laid.
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
I see!!! I see the light now!!! I see it all now!!! I have been
saved!!! If your super doper kernel autoconfigurator goes into the kernel
source tree then all of geekdom will have a possibility of getting laid.
Marvelous. Absolutely marvelous. I always knew coding would be able to
overcome any kind of obstacle for us, even this one. Horrah. 8-D
8-D Of course wantabe geek (if there is such a thing) Melvin could
always do it the hard way. The experience might come in handy for the next
"internet" bubble to arise. With the knowledge he gains he can make enough
paper money to take care of the getting laid problem once and for all (or at
least until the next crash). Besides his current target seams way too easy
if he has a chance at her just because he entered "configure". 8-D
Well anyway seams CML2 is becoming a literal everything and the kitchen
sink. Wow. 8-D So far my new kernel is going to require Python to
configure it, will include an super doper hardware detector so that it can
customize my spiffy new kernel specifically to my hardware, will include
special kernel access for regular users to be able to read my hardware
configuration because its so evil to configure my kernel as root even though
I will have to be root to install it and probably be root to untar/ungzip it
into /usr/src and not to mention removing the old /usr/src/linux, did I read
new driver model for autoconfiguring kernel somewhere too?, and the kernel
will even included a spiffy X Windows, KDE, or gnome (hey why skimp now)
program that installs itself as an icon on the user desktop (no matter what
the distribution, linux-kernel will support all) which the user can then
click on to fire up the kernel self-configuration, self-compiler,
self-installer, and auto boot loader configurator so that Aunt Tilly or the
slutty girl El Geeko has his eyes on can see a "Click here to launch new
kernel" button on their screen after their first reboot, oh and of course we
can't forget that the kernel must know that its either succeeded or failed
so that it could tell the user that and either restore the previous boot
configuration or install itself as the user's new default kernel thus
voiding the plebeian's support contract. But no problem, I'm sure the new
kernel can take care of that too. Just give it time. 8-D
Hilarities aside, I wouldn't mind having a program to automatically
configure a kernel for a system via Windows-like hardware autoconfiguration.
However do have a couple of quick points.
1. Don't see any reason for the kernel hardware autoconfigurator to be
included in the kernel.
2. Don't see any reason the kernel hardware autoconfigurator cannot be
run as root. Actually see one very good reason why it shouldn't be able to
be run as a regular user. Probing certain hardware is inherently dangerous.
Machine can hang. Hardware could be probed to death. Heck a clever coder
could even make use of the user level access required to allow user hardware
autoconfiguration. Wiping disks, destroying flash roms, finding system
backdoors, etc, etc.
3. ISA is pretty much dead outside of certain standard PC equipment.
And of the remaining ISA out there, most in any machine than can still run a
Linux kernel effectively is most likely PNP ISA. Plus there are a few
fairly common ISA cards that can also be found easily. It seams that the
vast majority of Aunt Tillies will be served with just PCI autoconfiguration
and maybe PNP ISA configuration.
^ permalink raw reply
* [BUG] symlink problem with knfsd and reiserfs
From: Hans-Peter Jansen @ 2002-01-15 11:50 UTC (permalink / raw)
To: Neil Brown; +Cc: Trond Myklebust, linux-kernel
Hi Neil et al.,
during the last days, Trond and me was able to hunt a problem down
to $subject, which happens as follows:
It occurs with all 2.4 kernels, I've tested so far, but for reference:
Server: 2.4.18-pre3 on Dual P3/500 exports reiserfs partitions
Client: Diskless 2.4.18-pre3 on Athlon 1.2 GHz
When building lm_sensors-2.6.2 on the client, I could easily reproduce
this:
gcc -shared -Wl,-soname,libsensors.so.1 -o lib/libsensors.so.1.2.0
lib/data.lo lib/general.lo lib/error.lo lib/chips.lo lib/proc.lo
lib/access.lo lib/init.lo lib/conf-parse.lo lib/conf-lex.lo -lc
rm -f lib/libsensors.so.1
ln -sfn libsensors.so.1.2.0 lib/libsensors.so.1
make: stat:lib/libsensors.so.1: Eingabe-/Ausgabefehler
rm -f lib/libsensors.so
ln -sfn libsensors.so.1.2.0 lib/libsensors.so
In syslog, this message appears:
Jan 15 00:21:03 elfe kernel: nfs_refresh_inode: inode 50066 mode changed,
0100664 to 0120777
In this case, ln managed to create an invalid link in the above sequence.
Really bad is, you cannot get around this within the client. Within the
server, the link is ok, but on the client, ls -l lib throws a
ls: lib/libsensors.so.1: Eingabe-/Ausgabefehler
A comment from Trond << EOC
It is telling you that the server has a blatant bug: it is first
telling the client that the inode 50066 is a regular file, then
it changes it to a link.
When this happens, the RFCs state that the server is supposed to
change the NFS filehandle. The client *does* check the filehandle, so
if the server had updated it correctly, you would not have had a
problem.
EOC
A least, Trond was able to get me around it with this patch, but
I would be nice to fix the real problem instead (b/c the build
feels noticable slower with it):
--- linux-2.4.18-up/fs/nfs/dir.c.orig Fri Jan 11 23:06:38 2002
+++ linux-2.4.18-up/fs/nfs/dir.c Mon Jan 14 23:52:17 2002
@@ -619,6 +619,8 @@
nfs_complete_unlink(dentry);
unlock_kernel();
}
+ if (is_bad_inode(inode))
+ force_delete(inode);
iput(inode);
}
--- linux-2.4.18-up/fs/nfs/inode.c.orig Fri Jan 11 23:08:00 2002
+++ linux-2.4.18-up/fs/nfs/inode.c Mon Jan 14 23:53:10 2002
@@ -699,6 +699,8 @@
return 0;
if (memcmp(&inode->u.nfs_i.fh, fh, sizeof(inode->u.nfs_i.fh)) != 0)
return 0;
+ if (is_bad_inode(inode))
+ return 0;
/* Force an attribute cache update if inode->i_count == 0 */
if (!atomic_read(&inode->i_count))
NFS_CACHEINV(inode);
An noted, this is a longer standing problem here, but with libsensors build,
I could easily reproduce this. Do yoou?
Any chance to get this fixed soon?
Cheers,
Hans-Peter
^ permalink raw reply
* Re: [linux-lvm] summary of what I need to do to mount snapshot on XFS
From: Andreas Dilger @ 2002-01-15 11:48 UTC (permalink / raw)
To: Adrian Head; +Cc: linux-lvm
In-Reply-To: <E16QVD9-0003HS-00@hermes.sistina.com>
On Jan 16, 2002 01:09 +1000, Adrian Head wrote:
> On Wed, 16 Jan 2002 00:16, Heinz J . Mauelshagen wrote:
> > > The lvm.c change you talk about I assume is the LVM_VFS_ENHANCEMENT
> > > change? For some reason when adding the lvm-1.0.1 upgrade patch this
> > > disappears from lvm.c I have been able to get this to compile with the
> > > change but I have forgoten what I did.
> > >
> > > This is one question I would like answered by the LVM gurus: should
> > > #define LVM_VFS_ENHANCEMENT still be there after upgrading to lvm-1.0.1?
> >
> > Yes.
>
> I have found that using the generated lvm-1.0.1 upgrade patch that the
> #define LVM_VFS_ENHANCEMENT gets removed. If all I do is add it back in
> manually - do I need to worry about other areas of the code that also need
> touch-ups? How would I tell?
Well, when you generate a new LVM patch it will just do a "diff" between
the lvm.c file in the LVM/kernel directory and the linux/md/lvm.c file.
If the VFS-lock patch is applied to the kernel sources and not the
LVM/kernel sources, it will be removed by the diff, meaning you will
need to apply the VFS-lock patch to the kernel again.
If you find you are doing a lot of patching, you could apply the VFS-lock
patch to the LVM/kernel/lvm.c file, and then subsequent patches that you
create will not have this part removed.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply
* Re: Problem with ServerWorks CNB20LE and lost interrupts
From: Maciej W. Rozycki @ 2002-01-15 11:44 UTC (permalink / raw)
To: Keith Owens; +Cc: Linux Kernel
In-Reply-To: <31989.1011042290@ocs3.intra.ocs.com.au>
On Tue, 15 Jan 2002, Keith Owens wrote:
> > The "noapic" option should probably get removed -- it was meant as a
> >debugging aid (as many of the "no*" options) at the early days of I/O APIC
> >support, I believe... Now the support is pretty stable.
>
> Intel 440GX chipsets hang during SCSI probe with UP kernels unless you
> use noapic. It works with SMP but many installers use UP kernels.
> Removing noapic will break install on all 440GX machines, there are a
> lot of them out there.
Now, is that a chipset problem or a firmware (MP table) one? If the
former, we should code a workaround triggered by the chipset's PCI ID, so
the I/O APIC path works, otherwise vendors should fix their firmware. For
UP systems a simple possibility is to remove the MP table altogether if
it's too hard to fix -- it is not needed at all.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: David Woodhouse @ 2002-01-15 11:40 UTC (permalink / raw)
To: esr; +Cc: Charles Cazabon, linux-kernel, arjan
In-Reply-To: <20020114142605.A4702@twoflower.internal.do>
esr@thyrsus.com said:
> He hard-compiled in that driver. lsmod(1) can't see it.
man dmesg.
Others have asserted that this kind of autoconfigure facility for
non-technical people isn't necessary.
I assert that it is actually harmful, and will make their life more
difficult.
My father's computer runs Linux. He doesn't need to recompile his kernels
or do any maintenance - I don't even trust him to run up2date for himself.
It's all he can manage to dial up and look at a web page so I can grab his
current IP address out of my logs, log in and do the rest.
If I get a bug report from him, it's not particularly coherent or useful.
Yet because he has a kernel binary which is identical to the one used by
many other more technical users out there, I can often match what he
complains about with the more useful bugreports in Bugzilla.
If he (or even I) compiled a custom kernel for him rather than using the
distro one, I wouldn't have a whelk's chance in a supernova of working out
WTF he was on about.
--
dwmw2
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Martin Knoblauch @ 2002-01-15 11:38 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: russ
> Re: [2.4.17/18pre] VM and swap - it's really unusable
>
>
> This is getting silly ... feeback like "ll is better than PK", "feels
> smooth", "is reponsive", "my kernel
> compile is faster than yours", etc. is not getting us any closer to the
> "how" of making a better kernel.
>
> What's the goal? How should SMP and NUMA behave? How is success measured?
>
> It would be good to be very clear on the ultimate purpose before making
> radical changes. All of
> these changes are dancing around some vague concept of
> reponsiveness...so define it!
>
OK, just my set of goals/requirements for a usable/production kernel:
- working VM under a broad set of loads. Working means fair/fitting
treatment of cache vs. process memory, no OOM killing processes when
there is plenty memory in "free+buffer+cache", no unnecessary swapping
out of processes if there is plenty of "free+buffer+cache" memory.
- good/great interactive feel. This means no loss of interactivity due
to cache vs. process memory issues. This means no loss of interactivity
due to heavy IO.
- Good enough worst case latency for "amateur" audio/DVD playback.
What *I* do not need it "hard real-time" with 101% guaranteed response
times.
What *I* want is to see my goals in the stock kernel, without needing
to apply a weird set of patches :-)
How we get there I do not care to much. If -aa can solve the VM
problems, fine. If rmap solves them, great. Just bring a working,
maintainable solution in.
Ditto for LL vs. preempt.
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: Martin.Knoblauch@TeraPort.de
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --the elegant solution)
From: Reid Hekman @ 2002-01-15 11:35 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201151235110.28503-100000@netfinity.realnet.co.sz>
On Tue, 2002-01-15 at 04:40, Zwane Mwaikambo wrote:
> Normal users should _never_ have to use
> kernel.org trees.
Yikes! Sayings about never saying "never" aside... I should think the
goal is for everyone to be able to use kernel.org trees with reasonable
expectations. I'd like to see the day when distros can include a
pristine tree. I don't expect it, and the need for outside trees isn't
going away, but I'd like to see kernel.org be the canonical Linux for
more production systems, development starts, and non-i386 arch's.
With respect to Aunt Tillie, hardware discovery and kernel configuration
are separate issues. Can't the hardware probes be a separate package?
The autoconfigurator I think will be useful, but can't the configurator
just be dependent on outside packages like other functionality is
dependent on isdn4k-utils or iptables?
Regards,
Reid "thinking this is getting offtopic" Hekman
--
Current: reid.hekman@ndsu.nodak.edu
Permanent: hekman@acm.org
^ permalink raw reply
* Re: ide.2.2.21.05042001-Ole.patch.gz
From: Krzysztof Oledzki @ 2002-01-15 11:35 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201112043340.14442-100000@dark.pcgames.pl>
Hello,
I have just made ide.2.2.21.01152002-Ole patch:
o backport from ide.2.4.16.12102001.patch: pdc202xx.c - ver 0.30
- no 48-bit lba - this requires changes in other files:
ide-disk.c, ide.c, ide.h, ... Maybe in future...
o fix missing DEVID_MR_IDE definition in ide-pci.c for VIA_82C576_1
o add PROMISE_20268R, PROMISE_20269, PROMISE_20275 in ide-pci.c
o add CONFIG_PDC202XX_FORCE option into Config.in, ide-pci.c
BTW: why the pdc202xx.c file still has "Version 0.30 Mar. 18, 2000"?
It has been changed since that time! :)
After all this changes, pdc202xx.c driver still works for my PDC20265 :)
So, if there is no problem with ide.2.4.16.12102001 my patch should also
works, maybe even for 20268R, 20269 and 20275 chipsets. ;-)
Best regards,
Krzysztof Oledzki
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: Keith Owens @ 2002-01-15 11:35 UTC (permalink / raw)
To: Rob Landley; +Cc: Linux Kernel List
In-Reply-To: <20020114222101.ZPUW15906.femail44.sdc1.sfba.home.com@there>
On Mon, 14 Jan 2002 09:19:01 -0500,
Rob Landley <landley@trommello.org> wrote:
>How much of the build process for the initramfs will be integrated with the
>kernel build? Since the kernel won't boot without a matching initramfs, I
>take it that some kind of initramfs will be a kernel build target now?
>
>There's been a lot of talk about having the source for a mini-libc (uclibc,
>dietlibc, some combo) in the kernel tree, and other people saying we should
>just grab the binary for build purposes. The most obvious model I can think
>of for klibc staying seperate from the kernel is the user-space
>pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel.
>
>The klibc source/binary debate still seems to be ongoing, but apart from
>that, will the build process for initramfs be part of the kernel build or not?
I am in two minds about this (but I am at one with my duality). Part
of me says that users will want to tweak the initramfs process and they
may want to use different versions of klibc, so klibc and building
initramfs should be outside the kernel build. Another part says that
users have to build initramfs before doing the install so initramfs and
klibc should be part of kbuild.
It will probably end up with klibc as part of the kernel tarball
supported by kbuild. Generating initramfs will be done by a script,
kbuild will supply a sample but users can copy and change the sample to
suit their own requirements.
^ permalink raw reply
* 2.2.21pre2 VIA IDE lockup during boot
From: Jani Forssell @ 2002-01-15 11:30 UTC (permalink / raw)
To: linux-kernel; +Cc: Vojtech Pavlik, alan
I reported earlier about a lockup during boot with a VIA KT133 (Abit KT7)
based motherboard using the 2.2.21pre2 kernel. We now tried Krzysztof
Oledzki's patch which has the new 2.4.x kernel VIA driver and Andre
Hedrick's
ide.2.2.19.05042001 patch ported to 2.2.21pre2. This version also locked up
in similar fashion.
We added some debug prints to disable_irq() so that we get the stack trace
when it is called with IRQ 14 as the parameter. It seems that it gets stuck
in the while loop waiting for IRQ_INPROGRESS.
Some combinations of IDE devices work, but the following triggers the
problem:
(the same combination does work with a 2.4.18pre2 kernel):
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
HPT370: IDE controller on PCI bus 00 dev 98
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
HPT370: using 33MHz PCI clock
ide2: BM-DMA at 0xe400-0xe407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xe408-0xe40f, BIOS settings: hdg:pio, hdh:pio
hda: SAMSUNG SV8004H, ATA DISK drive
hdb: CD-ROM 52X/AKH, ATAPI CDROM drive
[Trace #1] Called disable_irq with IRQ 14
[Trace #2] Called disable_irq with IRQ 14
hdc: SAMSUNG SV8004H, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
[Trace #3] Called disable_irq with IRQ 14
Trace #1:
Trace; c010a0ad <disable_irq+1d/44>
Trace; c01ec060 <error_table+ea0/35c0>
Trace; c01853dc <ide_config_drive_speed+74/384>
Trace; c0109ddf <do_8259A_IRQ+7f/a8>
Trace; c0109dfd <do_8259A_IRQ+9d/a8>
Trace; c01994a3 <via_set_drive+53/168>
Trace; c0183ffa <ide_delay_50ms+e/18>
Trace; c0196aaf <do_probe+20b/220>
Trace; c01995f5 <via82cxxx_tune_drive+3d/68>
Trace; c0197013 <probe_hwif+257/268>
Trace; c019790b <ideprobe_init+73/c4>
Trace; c0106000 <get_options+0/74>
Trace #2:
Trace; c010a0ad <disable_irq+1d/44>
Trace; c01ec060 <error_table+ea0/35c0>
Trace; c01853dc <ide_config_drive_speed+74/384>
Trace; c01994a3 <via_set_drive+53/168>
Trace; c01995f5 <via82cxxx_tune_drive+3d/68>
Trace; c0197013 <probe_hwif+257/268>
Trace; c019790b <ideprobe_init+73/c4>
Trace; c0106000 <get_options+0/74>
Trace; c0106000 <get_options+0/74>
Trace; c0106093 <init+7/150>
Trace; c0107a37 <kernel_thread+23/30>
Trace #3:
Trace; c010a0ad <disable_irq+1d/44>
Trace; c01ec060 <error_table+ea0/35c0>
Trace; c01853dc <ide_config_drive_speed+74/384>
Trace; c01994a3 <via_set_drive+53/168>
Trace; c020444f <dm_head_vals.500+4327/46f8>
Trace; c0153359 <proc_register+15/80>
Trace; c01996a8 <via82cxxx_dmaproc+88/b8>
Trace; c0184dac <ide_register_subdriver+80/d0>
Trace; c019bf6d <idedisk_init+15/98>
Trace; c0106000 <get_options+0/74>
Trace; c0106000 <get_options+0/74>
Trace; c0106093 <init+7/150>
Trace; c0107a37 <kernel_thread+23/30>
lspci:
0:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 03)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev
03)
The third trace is where it gets stuck. If anyone has any pointers as to how
to try to further debug or isolate this problem, we are willing to run more
tests.
Jani Forssell
jani.forssell@viasys.com
^ permalink raw reply
* [LARTC] how to shape vpn tarffic based on pptp
From: Chandrashekhar Joshi @ 2002-01-15 11:30 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
hello everybody,
can anyone shed some light on howto shape pptp based vpn traffic using htb.
that is allowing say "x kbps" to other internet services and "y kbps" to
pptp based vpn traffic with each class capable of borrowing from the
other incase of less traffic on either side.
thanks
shekhar
[-- Attachment #2: Type: text/html, Size: 377 bytes --]
^ permalink raw reply
* Re: [PATCH] page coloring for 2.4.17 kernel
From: Stephen C. Tweedie @ 2002-01-15 11:22 UTC (permalink / raw)
To: Jason Papadopoulos; +Cc: Stephen C. Tweedie, linux-mm
In-Reply-To: <3.0.6.32.20020114235555.007bfac0@boo.net>
Hi,
On Mon, Jan 14, 2002 at 11:55:55PM -0500, Jason Papadopoulos wrote:
> At 10:46 PM 1/14/02 +0000, you wrote:
>
> >> Hello. Please be patient with this, my first post to linux-mm.
> >> The included patch modifies the free list in the 2.4.17 kernel
> >> to support round-robin page coloring. It seems to work okay
> >> on an Alpha and speeds up a lot of number-crunching code I
> >> have lying around (lmbench reports some higher bandwidths too).
> >> The patch is a port of the 2.2.20 version that I recently posted
> >> to the linux kernelmailing list.
> >
> >Do you have numbers to show the sort of performance difference it
> >makes?
>
> It's a little difficult to tell with lmbench, since results can vary
> slightly from run to run.
That's an important aspect. Page colouring can often drastically
reduce the variance in run times for cache-intensive tasks. Average
and variance are both very much worth reporting.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: [OT] NFS locking with NFS-Root
From: Ladislav Michl @ 2002-01-15 10:20 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: linux-mips
In-Reply-To: <20020115100503.K15285@lug-owl.de>
On Tue, 15 Jan 2002, Jan-Benedict Glaw wrote:
> I've got an Indy now, and I want to make it install (with the current
> debian dbootstrap) on a NFS root. So I first go to mount the NFS server
> to /target and then proceed with the installation. All .deb's get
> downloaded, but they cannot be extracted because dpkg can't lock
> /var/lib/dpkg/lock .
>
> Dumb question: How do I make file locking (via fcntl(F_SETLK))
> functional?
place your lock files into the ramdisk.
ladis
^ permalink raw reply
* Re: Memory problem with bttv driver
From: Stephan von Krawczynski @ 2002-01-15 11:14 UTC (permalink / raw)
To: Gerd Knorr; +Cc: linux-kernel
In-Reply-To: <slrna480cv.68d.kraxel@bytesex.org>
On 15 Jan 2002 10:17:03 GMT
Gerd Knorr <kraxel@bytesex.org> wrote:
> MM wise it shouldn't make a difference whenever you are using 0.7.83 or
> 0.7.88 (I've mailed 0.7.88 patches to macelo for 2.4.18 btw). The 0.8.x
> versions have a complete different way to do the memory management.
No vmallocs?
Regards,
Stephan
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Horst von Brand @ 2002-01-15 11:00 UTC (permalink / raw)
To: Eric S. Raymond, Linux Kernel List
In-Reply-To: <20020114135412.D17522@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> said:
> Charles Cazabon <charlesc@discworld.dyndns.org>:
> > Yes, and yes. Aunt Tillie is running Linux because someone installed a
> > distribution for her.
> You don't know that. Maybe she installed it herself.
Linux-from-scratch or some such? In which case she'd better be able to
configure a custom kernel without help...
> > She is never going to need anything out of her kernel that her
> > vendor-shipped update kernels do not provide.
> *You can't know that.*
Right. But 99.9% of Aunt Tillies won't need anything else. To have
_everybody_ go through a lot of pain for the sake of 0.02% of Linux users
is silly. Better let Nephew Mervin keep the junkheap, and give Tilly a new
machine for her birthday.
> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.
Have you ever tried f.ex. Red Hat's installer and updater for the latest
versions (Just because it is the one I know best; other distribuctions have
similar facilities)? Have you tried a machine with Linux preinstalled?
Have you ever battled with Windows "autoconfiguration"?! _It doesn't
work_. At all. _Ever_. And that hasn't been an impediment to Aunt Tilly to
get a WinPC...
I just think that your idea is cool. You are just wasting effort on trying
to solve a non-problem, when there are lots of problems that could use your
talents.
But again, it's your own time.
--
Horst von Brand http://counter.li.org # 22616
^ permalink raw reply
* Re: atyfb in 2.5.2
From: David S. Miller @ 2002-01-15 10:57 UTC (permalink / raw)
To: tyketto; +Cc: linux-kernel
In-Reply-To: <20020115094953.GA24170@wizard.com>
From: A Guy Called Tyketto <tyketto@wizard.com>
Date: Tue, 15 Jan 2002 01:49:53 -0800
make[4]: Entering directory `/usr/src/linux/drivers/video/aty'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
-mpreferred-stack-boundary=2 -march=i686 -malign-functions=4
-DEXPORT_SYMTAB -c atyfb_base.c
atyfb_base.c: In function `aty_init':
atyfb_base.c:1989: incompatible types in assignment
Replace the "-1" on that line with "NODEV".
^ permalink raw reply
* Re: Autoconfiguration: Original design scenario
From: Russell King @ 2002-01-15 10:57 UTC (permalink / raw)
To: Giacomo Catenazzi; +Cc: Linux Kernel List, Eric S. Raymond
In-Reply-To: <3C4401CD.3040408@debian.org>
On Tue, Jan 15, 2002 at 11:17:49AM +0100, Giacomo Catenazzi wrote:
> [ In Alan diary, I found that he tried some drivers
> before to find the driver for Telsa new tape.
> Autoconfigure will help also hackers.
> Hmm. Was the card ISA? so forget the above example
> ]
Not particularly wanting to add to the rediculously high level of noise
on this list, but yes, that's happened to be once before, but for a PCI
ISDN card.
There weren't many clues on the card packaging what it was, and couldn't
find anything on the net about the card, so resourted to the "insmod this
module, does it do anything" approach. After many hours of prodding
around and reading source, turns out that it needed the hisax driver with
various random parameters.
I really don't see why hisax couldn't say "oh, you have an ISDN card with
IDs xxxx:xxxx, that's hisax type nn" and be done with it, rather than
needing to be told "pci id xxxx:xxxx type nn". Have a look at
drivers/isdn/hisax/config.c and wonder how the hell you take some random
vendors PCI ISDN card and work out how to drive it under Linux.
(For the record, the card was:
1397:2bd0 - Cologne Chip Designs GmbH - HFC-PCI 2BD0 ISDN
and the driver requirements were: hisax type 35 proto 2)
Realistically, I don't think any autoconfigurator will solve such cases
until these areas can be fixed up reasonably.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: crispin @ 2002-01-15 11:13 UTC (permalink / raw)
To: Horst von Brand, linux-kernel
In-Reply-To: <200201151045.g0FAjduU002847@tigger.cs.uni-dortmund.de>
On Tue, Jan 15, 2002 at 11:45:39AM +0100, Horst von Brand wrote:
> > On Mon, 14 Jan 2002, Alan Cox wrote:
>
> > > > 1. security, if you don't need any modules you can disable modules
> > > > entirly and then it's impossible to add a module without patching
> > > > the kernel first (the module load system calls aren't there)
>
> > > Urban legend.
>
> > If this is the case then why do I get systemcall undefined error messages
> > when I make a mistake and attempt to load a module on a kernel without
> > modules enabled?
>
> AFAIU the security improvement of no-modules are way overrated.
insmod knark.o
Crispin
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: Horst von Brand @ 2002-01-15 10:45 UTC (permalink / raw)
To: David Lang; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.40.0201141055410.22904-100000@dlang.diginsite.com>
> On Mon, 14 Jan 2002, Alan Cox wrote:
> > > 1. security, if you don't need any modules you can disable modules
> > > entirly and then it's impossible to add a module without patching
> > > the kernel first (the module load system calls aren't there)
> > Urban legend.
> If this is the case then why do I get systemcall undefined error messages
> when I make a mistake and attempt to load a module on a kernel without
> modules enabled?
AFAIU the security improvement of no-modules are way overrated.
[...]
> > > 3. simplicity in building kernels for other machines. with a monolithic
> > > kernel you have one file to move (and a bootloader to run) with modules
> > > you have to move quite a few more files.
> > tar or nfs mount; make modules_install.
> not on my firewalls thank you.
You keep compilers and stuff on your firewalls then?!
I get them over via ssh or by floppy/CD. Same idea.
--
Horst von Brand http://counter.li.org # 22616
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.