* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Maciej W. Rozycki @ 2003-01-08 20:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Mike Uhler, Dominic Sweetman, linux-mips
In-Reply-To: <20030108204408.A27888@linux-mips.org>
On Wed, 8 Jan 2003, Ralf Baechle wrote:
> We used to use just KSEG0 instead of KSEG0+entry*0x2000. That was running
> fine over years but had to be changed for the sake of two CPUs afair. There
> was some discussion on this list about this and I accepted the change by that
> time because Kevin imho correctly argued that the spec left it unspecified
> if an implementation is feeding addresses in an unmapped address space
> though the TLB.
Well, like it or not, CAMs do not like multiple matches -- up to a
physical damage even. So they should be avoided if possible. While KSEG0
won't match for any real address translation, there is a non-zero
probability of executing a tlbp for it as a result of buggy code or
execution gone wild (root running crashme?).
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Getting interface IP addresses with proc filesystem
From: Juan Gomez @ 2003-01-08 20:16 UTC (permalink / raw)
To: Burton Samograd; +Cc: linux-kernel, linux-kernel-owner
I proposed something along this lines but got lot of opposing remarks as I
wanted to identify a given interface as *primary*.
I think this feature is needed and we should add it to the kernel, I need
it, you need it, for sure someone else will need it.
Juan
|---------+---------------------------------->
| | Burton Samograd |
| | <kruhft@kruhft.dyndns.o|
| | rg> |
| | Sent by: |
| | linux-kernel-owner@vger|
| | .kernel.org |
| | |
| | |
| | 01/07/03 06:06 PM |
| | |
|---------+---------------------------------->
>-------------------------------------------------------------------------------------------------------------------------|
| |
| To: linux-kernel@vger.kernel.org |
| cc: |
| Subject: Getting interface IP addresses with proc filesystem |
| |
>-------------------------------------------------------------------------------------------------------------------------|
Hi all,
I'm curious how one goes about getting the current IP addresses held by a
machine. I saw some rather convoluted code in qmail that shows how to do
it but
it seems like a rather difficult (and future bug ridden if the interface
changes) piece of code and was thinking that a /proc/net interface would be
the
easiest solution, at least on the end user side.
My thinking goes along the lines of adding a file in /proc/net called
interfaces
(or something more appropriate) which gives the following type of listing:
eth0 12.35.23.58
eth0:0 192.168.0.1
lo 127.0.0.1
ppp0 45.3.3.89
etc
for each of the registered interfaces on the machine. Nice, simple and
shouldn't be too hard to implement, correct? Is this type of information
already present through some other mechanism that I haven't found yet?
Thanks in advance.
--
burton samograd
kruhft@kruhft.dyndns.org
http://kruhftwerk.dyndns.org
#### C.DTF has been removed from this note on January 08, 2003 by Juan
Gomez
^ permalink raw reply
* shutdown script
From: Wilson G. Hein @ 2003-01-08 20:06 UTC (permalink / raw)
To: Linux-Hams Mailing List
I'm wondering if someone has a script to close ax25 and netrom, etc
interfaces. I would presume it would have something to look at the pid's and
then kill the process. I wnat to plug it into /etc/sysconfig/network-scripts
to automate startup and close through the normal init scripts.
TIA,
Regards,
Willie, WJ3G
^ permalink raw reply
* Re: Linux 2.4.21-pre3-ac1
From: Maciej Soltysiak @ 2003-01-08 20:12 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <200301081824.h08IORR04757@devserv.devel.redhat.com>
> + NVIDIA nForce2 IDE PCI identifiers (Johannes Deisenhofer,
This has been confusing me lately, does nvidia produce a card with IDE ?
(similarily to some of creative labs' soundblasters ?)
Maciej
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Henrik Nordstrom @ 2003-01-08 20:33 UTC (permalink / raw)
To: Russ Dill; +Cc: Srinivasu.Vaduguri, linux-mtd
In-Reply-To: <1042054935.10724.10.camel@timmy>
On 8 Jan 2003, Russ Dill wrote:
> roll your own: Please, make a static compressed filesystem (like cramfs)
> that incorporates extra blocks, so that when the checksum is bad while
> initially writing the filesystem, or reading the file system (in the
> case where ecc can save the data), it rewrites this block to a free
> sector). It would seem like a simple modification to cramfs to me.
It would indeed be quite simple to adopt cramfs to bad blocks as long as
the superblock can be read. You only need to make a list of bad blocks,
and then teach mkcramfs about this, avoiding allocating the bad areas when
making the filesystem layout.
For generic bad-block management it would probably be more beneficial to
all to add a simple (and free from the (N)FTL patent issue) translation
layer capable of dealing with bad blocks and/or ECC I think.
Regards
Henrik
^ permalink raw reply
* Re:[BUG] cpci patch for kernel 2.4.19 bug
From: Scott Murray @ 2003-01-08 20:10 UTC (permalink / raw)
To: Rusty Lynch; +Cc: greg, harold.yang, linux-kernel, pcihpd-discuss
In-Reply-To: <200301081946.h08Jksh06332@linux.intel.com>
On Wed, 8 Jan 2003, Rusty Lynch wrote:
> From: "Yang, Harold" <harold.yang@intel.com>
> >
> > Hi, Scott & Greg:
> >
> > I have applied the cpci patch for kernel 2.4.19, and test it
> > thoroughly on ZT5084 platform. Two bugs are found:
> >
> > 1. In my ZT5084, the driver can't correctly detect the cPCI
> > Hot Swap bridge device. Two DEC21154 exist on ZT5084,
> > however, only one is the right bridge. The driver can't
> > distinguish them correctly.
>
> I just got a couple of ZT5541 peripheral master boards
> and can finally see what happens when an enumerable board
> is plugged into a ZT5084 chassis using a ZT5550 system master
> board.
>
> As of yet I have only tried a 2.5.54 kernel, but I see the
> same problems along with some other wacky behavior that I
> am trying to isolate.
>
> Now about the multiple DEC21154 devices ==> on my ZT5550 that
> is in system master mode, the first DEC21154 device is a bridge
> for the slots to the left of the system slots, and the second
> DEC21154 is a bridge for the right of the system slots.
Okay, that's what I originally wanted to determine from the lspci
output I requested when Harold mentioned this problem at the end
of November.
> So if I boot the system master (I'll talk about problems with
> hotswaping in another email) with a peripheral board plugged
> into one of the slots on the right of the master using the
> current 2.5.54 kernel then I run into problems the first time
> cpci_hotplug_core.c::check_slots() runs because it only looks
> at the first bus when trying to find the card that caused the
> #ENUM.
I assume by problems you mean that the cPCI event thread gets
shut down (which is what I'd expect), or do you mean something more
severe?
> The following patch will register each of the cpci busses instead
> of just the first one detected.
Your patch is better than Harold's hack, but I'm probably going to
try and think of some other alternative, as the while loop idea
doesn't handle the possibility of someone having a 21154 bridge
on a PMC card or actually as a bridge on a cPCI card. The original
code doesn't really handle that possiblity either, so I'll need to
cook up something better anyway.
> NOTE: I'm a little worried that the right way to do this is to
> properly initialize the RSS bits, or at least see how the
> chassis is configured via the RSS bits to determine which
> cpci bus to register. The ZT5084 doesn't have near as many
> configurations as newer designs like the ZT5088.
[snip]
I will investigate reading the active bus(es) out of the HC, as I've
gotten the documentation for the HC from Performance Tech, I was just
too busy before Christmas to dig into it then. I'll try and have
something that attempts to handle your ZT5084 chassis done in a few
days.
Scott
--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: scottm@somanetworks.com
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: Andrew McGregor @ 2003-01-08 20:09 UTC (permalink / raw)
To: H. Peter Anvin, linux-kernel
In-Reply-To: <avht3k$qpo$1@cesium.transmeta.com>
Actually, talking to some people off-list, I realised that what happened
with the instances I saw was probably that the packets were corrupted
inside the host, somewhere after the ethernet checksum had done its job.
DMA problems or a slow address line on some RAM somewhere could easily beat
the TCP checksum, but as many folks have pointed out, ethernet CRC is much
stronger.
Having seen something odd like that in practice, I overestimated the
probability of these problems.
It was also pointed out that iSCSI also makes it's CRC optional only if
there is some other mechanism (ESP, AH or some other high-integrity
transport) providing the data integrity. Partly this is because that
checksum is the same as used by Fiber Channel, and is therefore available
'for free' in some, but not all, hardware, so there needs to be another way
to integrity protect the data.
Andrew
--On Wednesday, January 08, 2003 11:10:44 -0800 "H. Peter Anvin"
<hpa@zytor.com> wrote:
> Followup to: <20030107053146.A16578@kerberos.ncsl.nist.gov>
> By author: Olivier Galibert <galibert@pobox.com>
> In newsgroup: linux.dev.kernel
>>
>> On Tue, Jan 07, 2003 at 01:39:38PM +1300, Andrew McGregor wrote:
>> > Ethernet and TCP were both designed to be cheap to evaluate, not the
>> > absolute last word in integrity. There is a move underway to provide
>> > an optional stronger TCP digest for IPv6, and if used with that then
>> > there is no need for the iSCSI digest. Otherwise, well, play dice
>> > with the data. Loaded in your favour, but still dice.
>>
>> Ethernet's checksum is a standard crc32, with all the usual good
>> properties and, at least on FE and lower, 1500bytes max of payload.
>> So it's quite reasonable. TCP's checksum, though, is crap.
>>
>> I'm not entirely sure how crc32 would behave on jumbo frames.
>>
>
> AUTODIN-II CRC32 (the one used by Ethernet) is stable up to 11454
> bytes. The jumbo frame size was chosen as the largest multiple of the
> standard IP payload size to fit within this number.
>
> -hpa
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Thomas Gleixner @ 2003-01-08 20:27 UTC (permalink / raw)
To: Russ Dill, Srinivasu.Vaduguri; +Cc: linux-mtd
In-Reply-To: <1042054935.10724.10.camel@timmy>
On Wednesday 08 January 2003 20:42, Russ Dill wrote:
> NAND *will* have bad blocks, cramfs does not handle bad blocks. There
> isn't an elegant solution for this right now, but here are some options:
> yaffs: desgined for NAND, but has no compression
Solid, but no compression
> jffs2: The NAND code is pretty new, and the journalling is probably
> overkill for your application, but it will work, and should be able to
> adapt to bad blocks.
The code is pretty new in comparison to Makefile V1.0, but it's used in
production system and can be considered "stable".
It's really a realiable rootfs.
> roll your own: Please, make a static compressed filesystem (like cramfs)
> that incorporates extra blocks, so that when the checksum is bad while
> initially writing the filesystem, or reading the file system (in the
> case where ecc can save the data), it rewrites this block to a free
> sector). It would seem like a simple modification to cramfs to me.
Don't reinvent the wheel! :)
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
^ permalink raw reply
* Re: Killing off the boot sector (was: [STATUS 2.5] January 8, 2002)
From: H. Peter Anvin @ 2003-01-08 20:03 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3E1C2208.6727.5370CB@localhost>
Followup to: <3E1C2208.6727.5370CB@localhost>
By author: "Guillaume Boissiere" <boissiere@adiglobal.com>
In newsgroup: linux.dev.kernel
>
> 179 nor bugme-janitors@lists.osdl.org OPEN boot from 21
> sec/track floppy
>
Can we *please* kill off the stupid in-kernel boot sector? The
probing method it uses to determine geometry is unreliable (doesn't
work on anything but true legacy floppies, not IDE, not USB, not
firewire); it generates these kinds of requests; doesn't handle
large-size kernels; hard-codes the use of address 0x90000 which isn't
available on all machines; and overall promotes what's fundamentally
bad practice.
People keep asking what's the harm in keeping it, and the answer is,
quite simply: "because people continue to try to use it."
Here is a patch that guts it to print an error message. It's even
tested.
--- linux-2.5.54/arch/i386/boot/bootsect.S.dist Wed Jan 8 11:35:52 2003
+++ linux-2.5.54/arch/i386/boot/bootsect.S Wed Jan 8 11:52:16 2003
@@ -4,29 +4,13 @@
* modified by Drew Eckhardt
* modified by Bruce Evans (bde)
* modified by Chris Noe (May 1999) (as86 -> gas)
- *
- * 360k/720k disk support: Andrzej Krzysztofowicz <ankry@green.mif.pg.gda.pl>
+ * gutted by H. Peter Anvin (Jan 2003)
*
* BIG FAT NOTE: We're in real mode using 64k segments. Therefore segment
* addresses must be multiplied by 16 to obtain their respective linear
* addresses. To avoid confusion, linear addresses are written using leading
* hex while segment addresses are written as segment:offset.
*
- * bde - should not jump blindly, there may be systems with only 512K low
- * memory. Use int 0x12 to get the top of memory, etc.
- *
- * It then loads 'setup' directly after itself (0x90200), and the system
- * at 0x10000, using BIOS interrupts.
- *
- * NOTE! currently system is at most (8*65536-4096) bytes long. This should
- * be no problem, even in the future. I want to keep it simple. This 508 kB
- * kernel size should be enough, especially as this doesn't contain the
- * buffer cache as in minix (and especially now that the kernel is
- * compressed :-)
- *
- * The loader has been made as simple as possible, and continuous
- * read errors will result in a unbreakable loop. Reboot by hand. It
- * loads pretty fast by getting whole tracks at a time whenever possible.
*/
#include <asm/boot.h>
@@ -59,359 +43,47 @@
.global _start
_start:
-# First things first. Move ourself from 0x7C00 -> 0x90000 and jump there.
+ # Normalize the start address
+ jmpl $BOOTSEG, $start2
- movw $BOOTSEG, %ax
- movw %ax, %ds # %ds = BOOTSEG
- movw $INITSEG, %ax
- movw %ax, %es # %ax = %es = INITSEG
- movw $256, %cx
- subw %si, %si
- subw %di, %di
- cld
- rep
- movsw
- ljmp $INITSEG, $go
-
-# bde - changed 0xff00 to 0x4000 to use debugger at 0x6400 up (bde). We
-# wouldn't have to worry about this if we checked the top of memory. Also
-# my BIOS can be configured to put the wini drive tables in high memory
-# instead of in the vector table. The old stack might have clobbered the
-# drive table.
-
-go: movw $0x4000-12, %di # 0x4000 is an arbitrary value >=
- # length of bootsect + length of
- # setup + room for stack;
- # 12 is disk parm size.
- movw %ax, %ds # %ax and %es already contain INITSEG
+start2:
+ movw %cs, %ax
+ movw %ax, %ds
+ movw %ax, %es
movw %ax, %ss
- movw %di, %sp # put stack at INITSEG:0x4000-12.
+ movw $0x7c00, %sp
+ sti
+ cld
-# Many BIOS's default disk parameter tables will not recognize
-# multi-sector reads beyond the maximum sector number specified
-# in the default diskette parameter tables - this may mean 7
-# sectors in some cases.
-#
-# Since single sector reads are slow and out of the question,
-# we must take care of this by creating new parameter tables
-# (for the first disk) in RAM. We will set the maximum sector
-# count to 36 - the most we will encounter on an ED 2.88.
-#
-# High doesn't hurt. Low does.
-#
-# Segments are as follows: %cs = %ds = %es = %ss = INITSEG, %fs = 0,
-# and %gs is unused.
-
- movw %cx, %fs # %fs = 0
- movw $0x78, %bx # %fs:%bx is parameter table address
- pushw %ds
- ldsw %fs:(%bx), %si # %ds:%si is source
- movb $6, %cl # copy 12 bytes
- pushw %di # %di = 0x4000-12.
- rep # don't worry about cld
- movsw # already done above
- popw %di
- popw %ds
- movb $36, 0x4(%di) # patch sector count
- movw %di, %fs:(%bx)
- movw %es, %fs:2(%bx)
-
-# Get disk drive parameters, specifically number of sectors/track.
-
-# It seems that there is no BIOS call to get the number of sectors.
-# Guess 36 sectors if sector 36 can be read, 18 sectors if sector 18
-# can be read, 15 if sector 15 can be read. Otherwise guess 9.
-# Note that %cx = 0 from rep movsw above.
+ movw $bugger_off_msg, %si
- movw $disksizes, %si # table of sizes to try
-probe_loop:
+msg_loop:
lodsb
- cbtw # extend to word
- movw %ax, sectors
- cmpw $disksizes+4, %si
- jae got_sectors # If all else fails, try 9
-
- xchgw %cx, %ax # %cx = track and sector
- xorw %dx, %dx # drive 0, head 0
- movw $0x0200, %bx # address = 512, in INITSEG (%es = %cs)
- movw $0x0201, %ax # service 2, 1 sector
- int $0x13
- jc probe_loop # try next value
-
-got_sectors:
- movb $0x03, %ah # read cursor pos
- xorb %bh, %bh
- int $0x10
- movw $9, %cx
- movb $0x07, %bl # page 0, attribute 7 (normal)
- # %bh is set above; int10 doesn't
- # modify it
- movw $msg1, %bp
- movw $0x1301, %ax # write string, move cursor
- int $0x10 # tell the user we're loading..
-
-# Load the setup-sectors directly after the moved bootblock (at 0x90200).
-# We should know the drive geometry to do it, as setup may exceed first
-# cylinder (for 9-sector 360K and 720K floppies).
-
- movw $0x0001, %ax # set sread (sector-to-read) to 1 as
- movw $sread, %si # the boot sector has already been read
- movw %ax, (%si)
-
- call kill_motor # reset FDC
- movw $0x0200, %bx # address = 512, in INITSEG
-next_step:
- movb setup_sects, %al
- movw sectors, %cx
- subw (%si), %cx # (%si) = sread
- cmpb %cl, %al
- jbe no_cyl_crossing
- movw sectors, %ax
- subw (%si), %ax # (%si) = sread
-no_cyl_crossing:
- call read_track
- pushw %ax # save it
- call set_next # set %bx properly; it uses %ax,%cx,%dx
- popw %ax # restore
- subb %al, setup_sects # rest - for next step
- jnz next_step
-
- pushw $SYSSEG
- popw %es # %es = SYSSEG
- call read_it
- call kill_motor
- call print_nl
-
-# After that we check which root-device to use. If the device is
-# defined (!= 0), nothing is done and the given device is used.
-# Otherwise, one of /dev/fd0H2880 (2,32) or /dev/PS0 (2,28) or /dev/at0 (2,8)
-# depending on the number of sectors we pretend to know we have.
-
-# Segments are as follows: %cs = %ds = %ss = INITSEG,
-# %es = SYSSEG, %fs = 0, %gs is unused.
-
- movw root_dev, %ax
- orw %ax, %ax
- jne root_defined
-
- movw sectors, %bx
- movw $0x0208, %ax # /dev/ps0 - 1.2Mb
- cmpw $15, %bx
- je root_defined
-
- movb $0x1c, %al # /dev/PS0 - 1.44Mb
- cmpw $18, %bx
- je root_defined
-
- movb $0x20, %al # /dev/fd0H2880 - 2.88Mb
- cmpw $36, %bx
- je root_defined
-
- movb $0, %al # /dev/fd0 - autodetect
-root_defined:
- movw %ax, root_dev
-
-# After that (everything loaded), we jump to the setup-routine
-# loaded directly after the bootblock:
-
- ljmp $SETUPSEG, $0
-
-# These variables are addressed via %si register as it gives shorter code.
-
-sread: .word 0 # sectors read of current track
-head: .word 0 # current head
-track: .word 0 # current track
-
-# This routine loads the system at address SYSSEG, making sure
-# no 64kB boundaries are crossed. We try to load it as fast as
-# possible, loading whole tracks whenever we can.
-
-read_it:
- movw %es, %ax # %es = SYSSEG when called
- testw $0x0fff, %ax
-die: jne die # %es must be at 64kB boundary
- xorw %bx, %bx # %bx is starting address within segment
-rp_read:
-#ifdef __BIG_KERNEL__ # look in setup.S for bootsect_kludge
- bootsect_kludge = 0x220 # 0x200 + 0x20 which is the size of the
- lcall *bootsect_kludge # bootsector + bootsect_kludge offset
-#else
- movw %es, %ax
- subw $SYSSEG, %ax
- movw %bx, %cx
- shr $4, %cx
- add %cx, %ax # check offset
-#endif
- cmpw syssize, %ax # have we loaded everything yet?
- jbe ok1_read
-
- ret
-
-ok1_read:
- movw sectors, %ax
- subw (%si), %ax # (%si) = sread
- movw %ax, %cx
- shlw $9, %cx
- addw %bx, %cx
- jnc ok2_read
-
- je ok2_read
-
- xorw %ax, %ax
- subw %bx, %ax
- shrw $9, %ax
-ok2_read:
- call read_track
- call set_next
- jmp rp_read
-
-read_track:
- pusha
- pusha
- movw $0xe2e, %ax # loading... message 2e = .
- movw $7, %bx
- int $0x10
- popa
-
-# Accessing head, track, sread via %si gives shorter code.
-
- movw 4(%si), %dx # 4(%si) = track
- movw (%si), %cx # (%si) = sread
- incw %cx
- movb %dl, %ch
- movw 2(%si), %dx # 2(%si) = head
- movb %dl, %dh
- andw $0x0100, %dx
- movb $2, %ah
- pushw %dx # save for error dump
- pushw %cx
- pushw %bx
- pushw %ax
- int $0x13
- jc bad_rt
-
- addw $8, %sp
- popa
- ret
-
-set_next:
- movw %ax, %cx
- addw (%si), %ax # (%si) = sread
- cmp sectors, %ax
- jne ok3_set
- movw $0x0001, %ax
- xorw %ax, 2(%si) # change head
- jne ok4_set
- incw 4(%si) # next track
-ok4_set:
- xorw %ax, %ax
-ok3_set:
- movw %ax, (%si) # set sread
- shlw $9, %cx
- addw %cx, %bx
- jnc set_next_fin
- movw %es, %ax
- addb $0x10, %ah
- movw %ax, %es
+ andb %al, %al
+ jz die
+ mov $0xe, %ah
xorw %bx, %bx
-set_next_fin:
- ret
-
-bad_rt:
- pushw %ax # save error code
- call print_all # %ah = error, %al = read
- xorb %ah, %ah
- xorb %dl, %dl
- int $0x13
- addw $10, %sp
- popa
- jmp read_track
-
-# print_all is for debugging purposes.
-#
-# it will print out all of the registers. The assumption is that this is
-# called from a routine, with a stack frame like
-#
-# %dx
-# %cx
-# %bx
-# %ax
-# (error)
-# ret <- %sp
-
-print_all:
- movw $5, %cx # error code + 4 registers
- movw %sp, %bp
-print_loop:
- pushw %cx # save count remaining
- call print_nl # <-- for readability
- cmpb $5, %cl
- jae no_reg # see if register name is needed
-
- movw $0xe05 + 'A' - 1, %ax
- subb %cl, %al
- int $0x10
- movb $'X', %al
int $0x10
- movb $':', %al
- int $0x10
-no_reg:
- addw $2, %bp # next register
- call print_hex # print it
- popw %cx
- loop print_loop
- ret
+ jmp msg_loop
-print_nl:
- movw $0xe0d, %ax # CR
- int $0x10
- movb $0xa, %al # LF
- int $0x10
- ret
-
-# print_hex is for debugging purposes, and prints the word
-# pointed to by %ss:%bp in hexadecimal.
-
-print_hex:
- movw $4, %cx # 4 hex digits
- movw (%bp), %dx # load word into %dx
-print_digit:
- rolw $4, %dx # rotate to use low 4 bits
- movw $0xe0f, %ax # %ah = request
- andb %dl, %al # %al = mask for nybble
- addb $0x90, %al # convert %al to ascii hex
- daa # in only four instructions!
- adc $0x40, %al
- daa
- int $0x10
- loop print_digit
- ret
+die:
+ # Allow the user to press a key, then reboot
+ xorw %ax, %ax
+ int $0x16
+ int $0x19
-# This procedure turns off the floppy drive motor, so
-# that we enter the kernel in a known state, and
-# don't have to worry about it later.
-# NOTE: Doesn't save %ax or %dx; do it yourself if you need to.
-
-kill_motor:
-#if 1
- xorw %ax, %ax # reset FDC
- xorb %dl, %dl
- int $0x13
-#else
- movw $0x3f2, %dx
- xorb %al, %al
- outb %al, %dx
-#endif
- ret
-sectors: .word 0
-disksizes: .byte 36, 18, 15, 9
-msg1: .byte 13, 10
- .ascii "Loading"
+bugger_off_msg:
+ .ascii "Direct booting from floppy is no longer supported.\r\n"
+ .ascii "Please use a boot loader program instead.\r\n"
+ .ascii "\n"
+ .ascii "Remove disk and press any key to reboot . . .\r\n"
+ .byte 0
+
-# XXX: This is a fairly snug fit.
+ # Kernel attributes; used by setup
-.org 497
+ .org 497
setup_sects: .byte SETUPSECTS
root_flags: .word ROOT_RDONLY
syssize: .word SYSSIZE
--- linux-2.5.54/arch/i386/boot/tools/build.c.dist Wed Jan 1 19:22:04 2003
+++ linux-2.5.54/arch/i386/boot/tools/build.c Wed Jan 8 11:53:32 2003
@@ -150,13 +150,10 @@
sz = sb.st_size;
fprintf (stderr, "System is %d kB\n", sz/1024);
sys_size = (sz + 15) / 16;
- /* 0x28000*16 = 2.5 MB, conservative estimate for the current maximum */
- if (sys_size > (is_big_kernel ? 0x28000 : DEF_SYSSIZE))
+ /* 0x40000*16 = 4.0 MB, reasonable estimate for the current maximum */
+ if (sys_size > (is_big_kernel ? 0x40000 : DEF_SYSSIZE))
die("System is too big. Try using %smodules.",
is_big_kernel ? "" : "bzImage or ");
- if (sys_size > 0xefff)
- fprintf(stderr,"warning: kernel is too big for standalone boot "
- "from floppy\n");
while (sz > 0) {
int l, n;
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: 16 NANDS
From: Thomas Gleixner @ 2003-01-08 20:23 UTC (permalink / raw)
To: David Woodhouse
Cc: manningc2, m.neiger, 'linux-mtd@lists.infradead.org'
In-Reply-To: <4752.1042013699@passion.cambridge.redhat.com>
On Wednesday 08 January 2003 09:14, David Woodhouse wrote:
> tglx@linutronix.de said:
> > The functions are not that different, but it's better to have a
> > little duplicated code instead of if (buswitdh == x) then else....
> > crap.
>
> Bear in mind that if/then/else crap can be hidden inside #defines fairly
> effectively, and optimises away perfectly in the case where you compile for
> only one buswidth -- unlike out-of-line function calls.
>
> What Nico did with cfi_read() et al is worth considering.
I have the option already built in to compile for one buswidth only, but if
you want to compile it for 8/16/32 3 different functions give you more code,
but also more speed and more flexibility for code maintainence
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
^ permalink raw reply
* Re: The only way around Mi
From: Rick A. Hohensee @ 2003-01-08 20:02 UTC (permalink / raw)
To: indigoid; +Cc: linux-kernel
In-Reply-To: <20030107231025.GE18508@higherplane.net>
>> I need some people that haven't forgotten how to use a computer to do
>> basic cleanups like convert "intelligence" in the CIA sense to
"strinfo",
>> shut down the war on herbs, eliminate using the tax laws as a form of
>> subsidy, et cetera. The better hackers will get cabinet positions.
>> Otherwise I'll promote from the existing staff.
>
>sounds a lot like 'executive orders' by tom clancy. not one of his
>better books, by the way
>
I don't read much fiction. Besides, like, the Washington Post. I'll have
to check out that Clancy title. Hmmmm, what was the last fiction I read?
"Tipping the Velvet". About a lesbian hooker in London before the
automobile. Didn't finish it.
Rick Hohensee
^ permalink raw reply
* Re: iptables u32 match code for review/testing/...
From: Don Cohen @ 2003-01-08 19:53 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20030108105646.GH9467@sunbeam.de.gnumonks.org>
Harald Welte writes:
> Hm. A recursive grep through the kernel doesn't find any occurrance of
> 'ipt_matchinfo' at all.
/usr/src/linux-2.4.18/include/linux/netfilter_ipv4/ipt_multiport.h
> > Ok, then I'll leave it at 10x10x10 (perhaps a lot of overhead for
> > a single match?)
> It also means that every single rule containing the u32 match will
> occupy smp_num_cpus*1000*sizeof(your structure) bytes of non-swappable
> kernel memory.
Well, not quite that bad. It's actually o(10x(10+10)). The structure
sizes seem to be 5+8 so actually using 1300 bytes. I don't know
whether there's more space wasted on alignment.
Would it work to make that 10 into a module parm (or three) ?
> > > I like the content (code/implementation/idea of having u32).
> > > The only issue is that it doesn't really fit into the current iptables
> > > architecture. Why?
> > > - because it is a whole classification engine on it's own
> > Why is this bad? I wrote it to do things I wanted to do but didn't
> > see how. I think that's good. If it subsumes a few others that are
> > out there, even better. (But it's almost certainly a lot slower than
> > any more specialized match, so they're still useful.)
>
> Sorry, I didn't make myself clear. if u32 is used the right way, it is
> way better than lots of the static matches within iptables. However, it
I don't know what "the right way" means. A more specific match will
be faster to execute and easier to specify. The advantage of u32 is
generality.
> is more like a replacement of the whole iptables packet matching engine,
> than a plugin/extension to it. Making it a plugin/extension will
> unfortunately become a sort-of clumsy approach. I don't blame or
> critisize you... this is not an issue of implementation, but a
> fundamental architectural problem.
Perhaps you should view it as temporary until something better
arrives. You might consider changing the architecture later.
My impression is that jamal <hadi@cyberus.ca> is well on the way to
using tc to replace iptables. And I begin to see that his approach
(or at least what I imagine to be his approach) might actually be
a lot more efficient.
I notice, btw, that u32 does not do what you'd want for ipv6.
In that case you want to look for a particular header, or of course,
for the end of the headers. Oh, well. Another project.
> yes. If you now would be as friendly to post it as a unified diff
> against current patch-o-matic CVS, attached in MIME format? (And for
> posting habits and/or coding style hints there are plenty of examples in
> the list archives respectively CVS).
As you can tell, I'm new at this. But will give it a try...
^ permalink raw reply
* RE: PCI code: why need outb (0x01, 0xCFB); ?
From: Nakajima, Jun @ 2003-01-08 19:10 UTC (permalink / raw)
To: H. Peter Anvin, linux-kernel
Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
We do not encourage use of byte accesses as it will not be supported in future platforms.
Thanks,
Jun
> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Wednesday, January 08, 2003 10:53 AM
> To: linux-kernel@vger.kernel.org
> Subject: Re: PCI code: why need outb (0x01, 0xCFB); ?
>
> Followup to: <F87sTOHYNhMwqvbLaKL0001615a@hotmail.com>
> By author: "fretre lewis" <fretre3618@hotmail.com>
> In newsgroup: linux.dev.kernel
>
> > 1. which device is at port address 0xCFB?
>
> Hopefully none.
>
> > 2. what is meaning of the writing operation "outb (0x01, 0xCFB);" for
> THIS
> > device?, it'seem that PCI spec v2.0 not say anything about it?
>
> It's trying to verify that the PCI northbridge does *NOT* respond to
> this (byte-wide) reference.
>
> -hpa
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Michael Milligan @ 2003-01-08 20:00 UTC (permalink / raw)
To: John Bradford; +Cc: Max Valdez, linux-kernel
In-Reply-To: <200301070859.h078xEnI000337@darkstar.example.net>
John Bradford wrote:
>>Is there any way to revert the stupid mistyping of "rm file *" on ext3??
>
> There is no simple way, no.
>
>>I hope there is a way, because I dont have a backup of some files i
>>mistakenly deleted
>
> The only thing I can suggest is this:
>
> * Do not write anything else to the partition, and immediately
> re-mount it read-only.
>
> E.G.:
>
> mount -oremount -oro /dev/hda3
>
> * Use dd to copy the entire contents of the partition to a file on
> another partition.
>
> E.G.:
>
> dd if=/dev/hda3 of=/partition_image
>
> * Search through that file for the fragments of your lost files.
>
This is where Lazarus from The Coroner's Toolkit might come in handy.
It's designed for ext2 though, not ext3, but it might work for you
nonetheless since ext3 is basically built on top of ext2.
http://www.cert.org/security-improvement/implementations/i046.03.html
Regards,
Mike
--
Michael Milligan -- Free Agent -- milli@acmeps.com
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Andrew McGregor @ 2003-01-08 19:59 UTC (permalink / raw)
To: Fabio Massimo Di Nitto, Wichert Akkerman; +Cc: netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.51.0301081849550.564@diapolon.int.fabbione.net>
--On Wednesday, January 08, 2003 19:05:36 +0100 Fabio Massimo Di Nitto
<fabbione@fabbione.net> wrote:
>
> I was able to reproduce the problem again. I have been using ethereal to
> sniff instead of tcpdump and gave out some more info.
>
> basically the icecast server at certain time (but i can't predict
> exactly in which situations) just send a FIN, ACK packet to the client.
> Basically to close the connection and after a few packets the client of
> course answer.What is strange that in the meanwhile there are still 3/4
> data packets coming from the server to the client.
>
> Regarding the network side I noticed the following:
>
> an average of 500ms to ping6 the server and 0 pkt loss
> few seconds before the FIN, ACK (server->client) and for about 6 pkts the
> average jumped to 2000ms
>
> I suspect that this network flap made the server thinking about
> <insert_here_whatever_term_is_more_appropriate> and decided to close
> the connection.
Probably on the server's side it got an ICMP Host Unreachable or two as
some router updated its tables, and decided to close the connection. The
FIN jumped the queue in one/several of the routers in the path, so it got
reordered relative to the data. This would imply that the router in
question had its route to you back by the time the FIN got there.
Wierd, but far from impossible.
>
> The full ethereal dump is available at
> http://www.fabbione.net/ice-xmms-ipv6.dump.bz2
>
> but PLEASE note that it is a 10MB file and Im on a slow adsl line so be
> "nice".
I think you provided enough info to tell what happened.
>
> Fabio
>
> PS Im afraid/happy that anyway the problem is not related to the kernel
> version we are running.
Doesn't look like a kernel problem.
Someone's got a dodgy link or a routing problem.
Andrew
^ permalink raw reply
* [PATCH] /proc/sys/kernel/pointer_size
From: John Levon @ 2003-01-08 19:59 UTC (permalink / raw)
To: torvalds, linux-kernel; +Cc: davem
OProfile needs to know the pointer size being used for the kernel,
on platforms with 32-bit userspace and 64-bit kernel. This patch adds
a simple ro sysctl that exports this information as suggested by davem
thanks,
john
diff -X dontdiff -Naur linux-linus/include/linux/sysctl.h linux/include/linux/sysctl.h
--- linux-linus/include/linux/sysctl.h 2003-01-03 02:59:14.000000000 +0000
+++ linux/include/linux/sysctl.h 2003-01-03 03:14:44.000000000 +0000
@@ -129,6 +129,7 @@
KERN_CADPID=54, /* int: PID of the process to notify on CAD */
KERN_PIDMAX=55, /* int: PID # limit */
KERN_CORE_PATTERN=56, /* string: pattern for core-file names */
+ KERN_POINTER_SIZE=57, /* size_t: sizeof(void *) */
};
diff -X dontdiff -Naur linux-linus/kernel/sysctl.c linux/kernel/sysctl.c
--- linux-linus/kernel/sysctl.c 2002-12-16 04:09:26.000000000 +0000
+++ linux/kernel/sysctl.c 2002-12-16 04:13:58.000000000 +0000
@@ -56,6 +56,9 @@
extern int pid_max;
extern int sysctl_lower_zone_protection;
+/* Needed when user-space is 32-bit with 64-bit kernel */
+static int pointer_size = (int)sizeof(void *);
+
/* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
static int maxolduid = 65535;
static int minolduid;
@@ -180,6 +183,8 @@
0644, NULL, &proc_dointvec},
{KERN_CAP_BSET, "cap-bound", &cap_bset, sizeof(kernel_cap_t),
0600, NULL, &proc_dointvec_bset},
+ {KERN_POINTER_SIZE, "pointer_size", &pointer_size, sizeof(int),
+ 0444, NULL, &proc_dointvec},
#ifdef CONFIG_BLK_DEV_INITRD
{KERN_REALROOTDEV, "real-root-dev", &real_root_dev, sizeof(int),
0644, NULL, &proc_dointvec},
^ permalink raw reply
* Re: [parisc-linux] Matrox Millenium II in C240
From: Peter 'p2' De Schrijver @ 2003-01-08 19:49 UTC (permalink / raw)
To: Grant Grundler
Cc: Matthew Wilcox, Peter 'p2' De Schrijver, parisc-linux
In-Reply-To: <20030106170059.GE9947@dsl2.external.hp.com>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
Hi,
>
> Hmmm. /proc/iomem should tell us which ranges dino/cujo are forwarding.
>
/proc/iomem in attachement.
> But looking at dino.c, it's clear the code is not handling multiple
> ranges correctly even if firmware did program it right.
>
> res = &dino_dev->hba.lmmio_space;
>
> lmmio_space needs to be an array.
> In HP speak, this is an "unsupported configuration".
>
> Elroy (lba_pci.c) suffers a similar problem with "directed ranges"
> (code currently only handles "distributed ranges"). At some point
> I'll get back to working on the lba code since it has a few other
> minor oustanding issues as well.
>
So, this basically means it won't work for now ?
Cheers,
Peter.
[-- Attachment #2: iomem-parisc --]
[-- Type: text/plain, Size: 941 bytes --]
00000000-1fffffff : System RAM
00000000-000009ff : PDC data (Page Zero)
00100000-002bffff : Kernel code
002c0000-003b5c1b : Kernel data
f0190001-f0190001 : led_data
f1000000-f1ffffff : GSC Bus [10/]
f1000000-f1000fff : Cujo
f1800000-f1ffffff : Cujo LMMIO
f2000000-f5ffffff : GSC Bus [8/]
f2000000-f2000fff : Dino
f2003000-f2003fff : Serial RS232
f2800000-f2ffffff : Dino LMMIO
f3ffb000-f3ffb3ff : tulip
f6000000-f7ffffff : GSC Bus [10/]
f8000000-fff7ffff : GSC Bus [8/]
ffd00000-ffdfffff : Lasi
ffd00000-ffd00fff : Lasi
ffd02000-ffd02fff : Parallel
ffd04000-ffd04fff : Lasi Harmony
ffd05000-ffd05fff : Serial RS232
ffd06000-ffd06fff : Lasi SCSI
ffd08000-ffd0800f : keyboard
ffd08100-ffd0810f : psaux
fff80000-fffaffff : Central Bus
fff88000-fff88fff : U2/Uturn
fff8a000-fff8afff : U2/Uturn
fffa0000-fffa0fff : CPU
fffb0000-fffdffff : Local Broadcast
fffe0000-ffffffff : Global Broadcast
^ permalink raw reply
* problem configuring for NFS between RH8 and RH6
From: Randall J. Parr @ 2003-01-08 19:48 UTC (permalink / raw)
To: Guarddog-user, netfilter, psyche-list
I have several RedHat 8, RedHat 7 and RedHat 6 servers.
I am using iptables on the RedHat 7 and 8 servers which I configure
using GuardDog.
I have been successful configured the firewall for and using NFS RH8 <->
RH8 and RH8 <-> RH7.
In the GuardDog, under Protocol, File Transfer, enabling NFS was
sufficient to allow RH8 <-> RH8 NFS.
However, when I try to use NFS RH8 <-> RH6 the firewall not allowing the
NFS transactions.
At first the log messages indicated RH8 -> RH6 port 111 was being
dropped. In GuardDog, enabling Protocol, Interactive, Sun RPC got past
this block.
But then the log messages indicated RH8 -> RH6 port 887 was being
dropped. Note that the dynamic port (in this example 887) changes every
time I restarted RH6 NFS.
I believe the problem is that RH6 NFS is using dynamic ports below 1024
and my RH8 kernel settings (sysctl.conf) and GuardDog settings limit the
dynamic port range to 1024 thru 65000.
I tried to change the dynamic port range via GuardDog but it does not
allow a value below 1024.
Note: if I disable the firewall temporarily (via GuardDog) NFS RH8 <->
RH6 works just fine.
I'm not sure how best (and most safely) to fix this.
QUES 1) Is it possible/safe to change the dynamic port range to
something below 1024? If it is, how do I do that in GuardDog?
QUES 2) Is it possible to configure the RH6 NFS to only use dynamic
ports above 1024? And if so, how? (I know how on RH7/8 but RH6 is, uh,
less "advanced").
QUES 3) Am I off base and this is not the problem at all?
Thanks
R.Parr
Temporal Arts
--
Psyche-list mailing list
Psyche-list@redhat.com
https://listman.redhat.com/mailman/listinfo/psyche-list
^ permalink raw reply
* Re: A humble request for help
From: Paulo Andre' @ 2003-01-08 19:56 UTC (permalink / raw)
To: Stefan, =?ISO-8859-1?B?Rw==?=; +Cc: linux-kernel
In-Reply-To: <3E1C4215.5080306@gorling.se>
On Wed, 08 Jan 2003 16:21:57 +0100
Stefan Görling <stefan@gorling.se> wrote:
> > Greg Kh,Wirex ?
I think GregKH works for IBM.
> > Jeff Garzik,Mandrake Software
And Jeff for RedHat.
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Ralf Baechle @ 2003-01-08 19:44 UTC (permalink / raw)
To: Mike Uhler; +Cc: Maciej W. Rozycki, Dominic Sweetman, linux-mips
In-Reply-To: <200301081933.h08JX1F09754@uhler-linux.mips.com>
On Wed, Jan 08, 2003 at 11:33:01AM -0800, Mike Uhler wrote:
> > They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> > patch.
>
> This is precisely what we use for our internal testing (which is also
> exported to MIPS32 and MIPS64 architecture licensees) to initialize the
> TLB. I have not yet seen a case where this fails, and would be interested
> in hearing about any case where it does fail.
We used to use just KSEG0 instead of KSEG0+entry*0x2000. That was running
fine over years but had to be changed for the sake of two CPUs afair. There
was some discussion on this list about this and I accepted the change by that
time because Kevin imho correctly argued that the spec left it unspecified
if an implementation is feeding addresses in an unmapped address space
though the TLB.
Ralf
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Andrew McGregor @ 2003-01-08 19:52 UTC (permalink / raw)
To: Wichert Akkerman, linux-kernel; +Cc: Maciej Soltysiak, netdev
In-Reply-To: <20030108170139.GL22951@wiggy.net>
Selective ACK is mandatory in IPv6 and uses a somewhat different algorithm,
so you shouldn't be seeing nearly as many ACKs as an IPv4 client would do
by default.
Andrew
--On Wednesday, January 08, 2003 18:01:39 +0100 Wichert Akkerman
<wichert@wiggy.net> wrote:
> Previously Maciej Soltysiak wrote:
>> I seem to be getting better results than you, i think that it is not an
>> issue of ipv6 implementation but simply the case of time sensitive
>> traffic fighting with other Internet traffic over tunnels through ipv4
>> networks.
>
> Actually, I don't follow this. How could any kind of traffic shaping
> result in my client not sending ACKs, which is what the tcpdump
> seems to indicate? I can understand packets being dropped which
> would result in retransmits, but that is not the case here.
>
> Wichert.
>
> (usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here)
>
> --
> Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
> A random hacker
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: observations on 2.5 config screens
From: Dave Jones @ 2003-01-08 19:50 UTC (permalink / raw)
To: Bill Davidsen
Cc: Robert Love, Adrian Bunk, Robert P. J. Day,
Linux kernel mailing list
In-Reply-To: <Pine.LNX.3.96.1030108132758.22872B-100000@gatekeeper.tmr.com>
On Wed, Jan 08, 2003 at 01:36:06PM -0500, Bill Davidsen wrote:
> I guess, depending on your definition of fundemental. I would put any
> option which affects the kernel as a whole in that category, myself.
> Compiling with frame pointers comes to mind, since every object file is
> changed and there are performance implications as well.
No-one other than kernel hackers should be playing with that option,
hence it's in the kernel hacking menu.
> Processor option would select the processor and any architecture dependent
> options, I would think. Something like "kernel characteristics" could have
> options like smp.
SMP isn't a processor option ?
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: 3CR990 question (Nearly unrelated to iSCSI)
From: Ion Badulescu @ 2003-01-08 19:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, nick
In-Reply-To: <20030108020033.GA6579@gtf.org>
On Tue, 7 Jan 2003 21:00:33 -0500, Jeff Garzik <jgarzik@pobox.com> wrote:
> On Tue, Jan 07, 2003 at 07:56:37PM -0500, nick@snowman.net wrote:
>> On Wed, 8 Jan 2003, Andrew McGregor wrote:
>> > > AH permits multiple digests, they also happen to correspond to the
>> > > hardware accelerated ones on things like the 3c990...
>> Speaking of which, did this driver which was mentioned ever occur?
>
> Two did, actually :)
Actually, the 3Com driver I cleaned up does not have support for the
hardware crypto chip. Maybe the other driver you were referring to
supports it?
> I hope we will see it appear in a kernel RSN
Indeed. :) That damn legalese in 3Com's license...
In the meantime, I can separately distribute it to people who need it:
<http://www.badula.org/3c990/>.
The latest version (LK1.0.1) properly supports big-endian architectures,
tested on a sparc64.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
^ permalink raw reply
* Re: tenth post about PCI code, need help
From: H. Peter Anvin @ 2003-01-08 19:48 UTC (permalink / raw)
To: root; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.3.95.1030108143728.31888A-100000@chaos.analogic.com>
Richard B. Johnson wrote:
> On 8 Jan 2003, H. Peter Anvin wrote:
>
>
>>Followup to: <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
>>By author: "Richard B. Johnson" <root@chaos.analogic.com>
>>In newsgroup: linux.dev.kernel
>>
>>>The problem is that he's discovered something that's not supposed
>>>to be in the code. Only 32-bit accesses are supposed to be made to
>>>the PCI controller ports. He has discovered that somebody has made
>>>some 8-bit accesses that will not become configuration 'transactions'
>>>because they are not 32 bits.
>>>
>>
>>Right. That's what the code is checking for.
>>
>> -hpa
>
> Somebody is very lucky the designer of the bus interface state-machine
> let him get away with it. This is a borderline "insane instruction" that
> could, on some (future?) machine, require a power-off to recover. This is
> NotGood(tm). It's like testing a fuse by shorting out a circuit. If it
> works, the circuit no longer works. If I doesn't, the circuit no longer
> works. Some things should not be tested.
>
If so, we will get an bug report rather than mysterious strange
behaviour. This is a good thing. (Amusingly enough, exactly this code
in the Linux kernel actually found a bug in one of the very early
versions of the Transmeta northbridge. It was fixed in firmware.)
-hpa
^ permalink raw reply
* Fix up dma_alloc_coherent with 64bit DMA masks on i386.
From: davej @ 2003-01-08 19:46 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Cset 1.808 in 2.4 never got propagated forward to 2.5
It's pretty much the same fix as below (s/!=/</), but with the following
changes
- This was a patch to pci_alloc_consistant(), which now seems to be
dma_alloc_coherent()
- Removal of the u32 cast
diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/pci-dma.c linux-2.5/arch/i386/kernel/pci-dma.c
--- bk-linus/arch/i386/kernel/pci-dma.c 2003-01-08 10:46:59.000000000 -0100
+++ linux-2.5/arch/i386/kernel/pci-dma.c 2003-01-08 11:02:50.000000000 -0100
@@ -19,7 +19,7 @@ void *dma_alloc_coherent(struct device *
void *ret;
int gfp = GFP_ATOMIC;
- if (dev == NULL || ((u32)*dev->dma_mask != 0xffffffff))
+ if (dev == NULL || (*dev->dma_mask < 0xffffffff))
gfp |= GFP_DMA;
ret = (void *)__get_free_pages(gfp, get_order(size));
^ 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.