* Re: Possible problem in asm/bitops.h
From: Tom Rini @ 2002-12-17 14:59 UTC (permalink / raw)
To: Georg Klug; +Cc: linuxppc-embedded
In-Reply-To: <FFECLICFNBJAHONLGAKMAEFOCHAA.gklug@giga-stream.de>
On Tue, Dec 17, 2002 at 10:10:09AM +0100, Georg Klug wrote:
> > I suspect the actual problem is that iproute2 only needs
> > a very small amount of what is in include/linux/inetdev.h
>
> That might be true. But would the solution be to copy the linux/inetdev.h
> to a local directory and change that file until it doesn't need the file
> asm/bitops.h anymore?
Correct.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: netstat and 2.5.5[12]
From: Anders Gustafsson @ 2002-12-17 15:02 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, joe user, linux-kernel
In-Reply-To: <20021217145931.GA1536@conectiva.com.br>
On Tue, Dec 17, 2002 at 12:59:31PM -0200, Arnaldo Carvalho de Melo wrote:
> > Happens here too.
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=103974450111945&w=2
> >
> > A cat /proc/net/tcp causes the same problem, so not tools problem.
>
> I'm looking into this, do you have ipv6 connections?
Yes, and I have daemons listening on ipv6.
--
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
^ permalink raw reply
* Re: netstat and 2.5.5[12]
From: Arnaldo Carvalho de Melo @ 2002-12-17 14:59 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: joe user, linux-kernel
In-Reply-To: <20021216124553.GA3727@gagarin>
Em Mon, Dec 16, 2002 at 01:45:53PM +0100, Anders Gustafsson escreveu:
> On Mon, Dec 16, 2002 at 01:06:32PM +0100, joe user wrote:
> > Is required a new net-tools package required to run 2.5.5[12]? If you run
> > netstat -t the process just hang forever, and is unkillable.
>
> Happens here too.
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103974450111945&w=2
>
> A cat /proc/net/tcp causes the same problem, so not tools problem.
I'm looking into this, do you have ipv6 connections?
- Arnaldo
^ permalink raw reply
* Re: [PATCHSET] PC-9800 addtional for 2.5.50-ac1 (21/21)
From: Alan Cox @ 2002-12-17 15:36 UTC (permalink / raw)
To: Osamu Tomita
Cc: YOSHIFUJI Hideaki / 吉藤英明,
Linux Kernel Mailing List
In-Reply-To: <3DFDE4FE.755F6651@cinet.co.jp>
Any chance of moving the EBDA to query to be something like
unsigned long get_bios_ebda(void)
and hiding it in the per platform includes (returning 0 for non I guess)
^ permalink raw reply
* unexpected IO-APIC
From: Christian Heimanns @ 2002-12-17 14:46 UTC (permalink / raw)
To: linux-smp
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
Hello kernel developers,
I'm the owner of a new mainboard:
MSI KT4L (MS-6712) with the new KT400 chipset. The CPU is a AMD Athlon
XP 2400+, assited by 512MB DDR-RAM (2700).
The Linux-Distribution I use is SuSE-8.1 with SuSE-kernel (uname -r)
2.4.19-4GB.
In the boot message (dmesg) I saw the request to give you a note.
Attached you will find the boot message (dmesg.txt).
With APIC disabled and ACPI=off everything is fine, but with APIC
enabled and ACPI=off I have some problems with my grafic adapter and
setterm -blank x. After blanking using APM and trying to wake up the
computer it freeze.
With regards,
--
Christian Heimanns (Germany)
heimanns@versanet.de
### Pinguine können nicht fliegen
- Pinguine stürzen auch nicht ab! ###
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 14542 bytes --]
Linux version 2.4.19-4GB (root@Athlon.suse.de) (gcc version 3.2) #1 Wed Nov 27 00:56:53 UTC 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data)
BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
511MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
found SMP MP-table at 000fb930
hm, page 000fb000 reserved twice.
hm, page 000fc000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
Advanced speculative caching feature present
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: VIA Product ID: VT5440B APIC at: 0xFEE00000
Processor #0 6:8 APIC version 17
I/O APIC #2 Version 3 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
Building zonelist for node : 0
Kernel command line: apic root=/dev/hda7 acpi=off hdc=ide-scsi hdd=ide-scsi max_scsi_luns=1 vga=794 init 3
ide_setup: hdc=ide-scsi
ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 2030.129 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 4050.12 BogoMIPS
Memory: 513900k/524224k available (1688k kernel code, 9936k reserved, 569k data, 168k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Before vendor init, caps: 0383fbff c1c3fbff 00000000, vendor = 2
Advanced speculative caching feature present
Disabling advanced speculative caching
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbf7 c1c3fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbf7 c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbf7 c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) XP 2400+ stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-12, 2-18, 2-19, 2-20, 2-22 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 20.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 001 01 0 0 0 0 0 1 1 51
07 001 01 0 0 0 0 0 1 1 59
08 001 01 0 0 0 0 0 1 1 61
09 001 01 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 001 01 0 0 0 0 0 1 1 71
0e 001 01 0 0 0 0 0 1 1 79
0f 001 01 0 0 0 0 0 1 1 81
10 001 01 1 1 0 1 0 1 1 89
11 001 01 1 1 0 1 0 1 1 91
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 001 01 1 1 0 1 0 1 1 99
16 000 00 1 0 0 0 0 0 0 00
17 001 01 1 1 0 1 0 1 1 A1
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ21 -> 0:21
IRQ23 -> 0:23
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2030.2271 MHz.
..... host bus clock speed is 270.6968 MHz.
cpu: 0, clocks: 2706968, slice: 1353484
CPU0<T0:2706960,T1:1353472,D:4,S:1353484,C:2706968>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20020829
ACPI: Disabled via blacklist or command line
PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ACPI tables contain no PCI IRQ routing entries
PCI: Probing PCI hardware (bus 00)
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router default [1106/3177] at 00:11.0
PCI->APIC IRQ transform: (B0,I6,P0) -> 17
PCI->APIC IRQ transform: (B0,I16,P0) -> 21
PCI->APIC IRQ transform: (B0,I16,P1) -> 21
PCI->APIC IRQ transform: (B0,I16,P2) -> 21
PCI->APIC IRQ transform: (B0,I16,P3) -> 21
PCI->APIC IRQ transform: (B0,I17,P0) -> 16
PCI->APIC IRQ transform: (B0,I18,P0) -> 23
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
PCI: Via IRQ fixup for 00:10.1, from 10 to 5
PCI: Via IRQ fixup for 00:10.0, from 11 to 5
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)
Starting kswapd
bigpage subsystem: allocated 0 bigpages (=0MB).
kinoded started
VFS: Diskquotas version dquot_6.5.0 initialized
aio_setup: num_physpages = 32764
aio_setup: sizeof(struct page) = 48
vesafb: framebuffer at 0xd0000000, mapped to 0xe080d000, size 65536k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:e9d0
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... found (1280x1024, 38795 bytes).
Console: switching to colour frame buffer device 132x45
fb0: VESA VGA frame buffer device
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L080AVVA07-0, ATA DISK drive
hdc: TOSHIBA DVD-ROM SD-M1712, ATAPI CD/DVD-ROM drive
hdd: PLEXTOR CD-R PX-W4012A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c03c9484, I/O limit 4095Mb (mask 0xffffffff)
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=10011/255/63, UDMA(100)
ide-floppy driver 0.99.newide
Partition check:
hda: hda1 hda2 < hda5 hda6 hda7 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 16 devices)
Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994
Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak.
ide-floppy driver 0.99.newide
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 264k freed
VFS: Mounted root (ext2 filesystem).
scsi: limiting sg entries to 204
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004
Type: CD-ROM ANSI SCSI revision: 02
Vendor: PLEXTOR Model: CD-R PX-W4012A Rev: 1.03
Type: CD-ROM ANSI SCSI revision: 02
reiserfs: found format "3.6" with standard journal
reiserfs: checking transaction log (ide0(3,7)) for (ide0(3,7))
reiserfs: using ordered data mode
Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Trying to move old root to /initrd ... failed
Unmounting old root
Trying to free ramdisk memory ... okay
Freeing unused kernel memory: 168k freed
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
Adding Swap: 658624k swap-space (priority 42)
MSDOS FS: IO charset iso8859-15
via-rhine.c:v1.10-LK1.1.14 May-3-2002 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
eth0: VIA VT6102 Rhine-II at 0xcc00, 00:10:dc:c0:6d:58, IRQ 23.
eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
eth0: Setting full-duplex based on MII #1 link partner capability of 45e1.
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
hcd.c: ehci-hcd @ 00:10.3, VIA Technologies, Inc. USB 2.0
hcd.c: irq 21, pci mem e4918f00
usb.c: new USB bus registered, assigned bus number 1
ehci-hcd.c: USB 2.0 support enabled, EHCI rev 1. 0
hub.c: USB hub found
hub.c: 6 ports detected
usb-uhci.c: $Revision: 1.275 $ time 01:48:07 Nov 27 2002
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 21
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 21
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0xd000, IRQ 21
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 4
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
uhci.c: USB Universal Host Controller Interface driver v1.1
hub.c: USB new device connect on bus3/1, assigned device number 2
usb.c: USB device 2 (vend/prod 0x46d/0xc00e) is not claimed by any active driver.
hub.c: USB new device connect on bus3/2, assigned device number 3
usb.c: USB device 3 (vend/prod 0x4b8/0x5) is not claimed by any active driver.
sg_attach: dev0=(21:0)
sg_attach: dev1=(21:1)
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sr1: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
mice: PS/2 mouse device common for all mice
usb.c: registered new driver hiddev
usb.c: registered new driver hid
input0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb3:2.0
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver usblp
printer.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04B8 pid 0x0005
printer.c: v0.11: USB Printer Device Class driver
IPv6 v0.8 for NET4.0
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
usb.c: registered new driver serial
usbserial.c: USB Serial support registered for Generic
usbserial.c: USB Serial Driver core v1.4
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
cdrom: open failed.
cdrom: open failed.
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 64
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 66
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 68
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 70
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 72
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 74
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 76
ide-scsi: hdd: unsupported command in request queue (0)
end_request: I/O error, dev 16:40 (hdd), sector 78
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 64
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 66
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 68
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 70
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 72
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 74
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 76
ide-scsi: hdc: unsupported command in request queue (0)
end_request: I/O error, dev 16:00 (hdc), sector 78
cdrom: open failed.
^ permalink raw reply
* RE: [PATCH] kNFSd - 2 of 7 - Revlaidate inodes after filehandle and name lookup in nfsd
From: Irina Slutsky @ 2002-12-17 14:36 UTC (permalink / raw)
To: nfs; +Cc: 'Brian Dixon', 'NeilBrown'
In-Reply-To: <E18O714-0000ot-00@notabene.cse.unsw.edu.au>
Thanks for this patch. Problem, this patch is addressing is very
important for me. This is the behaviors I am missing and is trying to
work around. When do you think this patch can be incorporated in the
official kernel release?
Small note: there is an inline routine
do_reavlidate(struct denty *) in the kernel
that could be used instead. It has all the "if"s checking inside.
I also have a question on the same topic:
Is there any particular reason for not allowing a fs to create file
handle for exported entry? I know the code is easier this way, but it
would be very useful.
Thanks
Irina Slutsky
-----Original Message-----
From: nfs-admin@lists.sourceforge.net
[mailto:nfs-admin@lists.sourceforge.net] On Behalf Of NeilBrown
Sent: Monday, December 16, 2002 8:59 PM
To: Marcelo Tosatti
Cc: nfs@lists.sourceforge.net
Subject: [NFS] [PATCH] kNFSd - 2 of 7 - Revlaidate inodes after
filehandle and name lookup in nfsd
The patch was written by Marc Eshel and Frank Schmuck.
It was received from "Brian Dixon" <dixonbp@us.ibm.com>
though I changed it slightly.
----------- Diffstat output ------------
./fs/nfsd/nfsfh.c | 7 +++++++
./fs/nfsd/vfs.c | 12 +++++++-----
2 files changed, 14 insertions(+), 5 deletions(-)
diff ./fs/nfsd/nfsfh.c~current~ ./fs/nfsd/nfsfh.c
--- ./fs/nfsd/nfsfh.c~current~ 2002-12-16 16:28:47.000000000 +1100
+++ ./fs/nfsd/nfsfh.c 2002-12-16 16:28:47.000000000 +1100
@@ -620,6 +620,13 @@ fh_verify(struct svc_rqst *rqstp, struct
switch (fh->fh_fileid_type) {
case 0:
dentry = dget(exp->ex_dentry);
+ /* need to revalidate the inode */
+ inode = dentry->d_inode;
+ if (inode->i_op &&
inode->i_op->revalidate)
+ if
(inode->i_op->revalidate(dentry)) {
+ dput(dentry);
+ dentry =
ERR_PTR(-ESTALE);
+ }
break;
default:
dentry =
find_fh_dentry(exp->ex_dentry->d_inode->i_sb,
diff ./fs/nfsd/vfs.c~current~ ./fs/nfsd/vfs.c
--- ./fs/nfsd/vfs.c~current~ 2002-12-16 16:28:47.000000000 +1100
+++ ./fs/nfsd/vfs.c 2002-12-16 16:28:47.000000000 +1100
@@ -168,11 +168,13 @@ nfsd_lookup(struct svc_rqst *rqstp, stru
mntput(mnt);
}
}
- /*
- * Note: we compose the file handle now, but as the
- * dentry may be negative, it may need to be updated.
- */
- err = fh_compose(resfh, exp, dentry, fhp);
+
+ if (dentry->d_inode && dentry->d_inode->i_op &&
+ dentry->d_inode->i_op->revalidate &&
+ dentry->d_inode->i_op->revalidate(dentry))
+ err = nfserr_noent;
+ else
+ err = fh_compose(resfh, exp, dentry, fhp);
if (!err && !dentry->d_inode)
err = nfserr_noent;
out:
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Dominic Sweetman @ 2002-12-17 14:35 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Jun Sun, Ralf Baechle, linux-mips
In-Reply-To: <Pine.GSO.3.96.1021217131352.7289A-100000@delta.ds2.pg.gda.pl>
> The i8259A doesn't work this way. With your proposed code the IRR
> is never cleared (which is a problem for edge-triggered interrupts
> -- such an interrupt gets signalled again once it's unmasked, until
> deasserted by a device). The i8259A only clears a bit in the IRR
> when it receives an ACK (it then copies the bit to the corresponding
> bit of the ISR) or when an interrupt goes away (a device deasserts
> it).
Just a few comments on the hardware:
As I recall, you can clear a stored edge-triggered interrupt using a
"specific EOI". In the 8080 microprocessor for which the 8259 was
designed, this command was magically communicated to the 8259 when the
CPU ran its "return from interrupt" instruction. I think even in the
8086 this had to be replaced with an explicit I/O cycle.
People not using x86 CPUs should consider putting the i8259 into
"special mask mode". Then it behaves simply and predictably,
providing an interrupt on any active unmasked input. You lose the
i8259 interrupt priority stuff, but this is only one of the
advantages. You'd need to be reasonably knowledgeable about the Linux
interrupt system to make this clean and compatible with the x86
versions, but then these troubles would be over for ever and you'd be
a Hero, First Class.
Alternatively, many MIPS systems have a hardware feature which enables
them to generate imitation-x86 interrupt acknowledge cycles, so you
can keep the 8259s in complete ignorance that they're not being
controlled by an x86.
--
Dominic Sweetman
MIPS Technologies
dom@mips.com
^ permalink raw reply
* Re: How to get the size of the block device ???? (Important)
From: Sean Neakums @ 2002-12-17 14:40 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.3.95.1021217093512.24416A-100000@chaos.analogic.com>
commence Richard B. Johnson quotation:
> On Tue, 17 Dec 2002, [iso-8859-1] Sanjay Kumar wrote:
>
>> Problem Summary : I need the size of the block device in bytes on
>> which my file system will be created. Actually, there is a feild
>> in the super block, needs the total no of blocks on the device
>> while while creating the filesystem. So, Can you Plz. help me out
>> of this problem.
>
> You make an ioctl() function for your file-system that returns the
> block-size that you selected when you designed the system.
The size of the block device is what is sought here, not the block
size of the filesystem.
Isn't there an ioctl for this? BLKSIZEGET or something?
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <sneakums@zork.net> | answers a prison for oneself.
\ |
^ permalink raw reply
* Re: How to get the size of the block device ???? (Important)
From: Nicholas Berry @ 2002-12-17 14:39 UTC (permalink / raw)
To: root, sanju93csd; +Cc: Matt_Domsch, linux-kernel
I think the question being asked is 'how do I find out how many block
long the device is?'
You can open it, seek to the end, then the file postiton will tell you
the size of the device.
Nik
>>> "Richard B. Johnson" <root@chaos.analogic.com> 12/17/02 09:36AM
>>>
On Tue, 17 Dec 2002, [iso-8859-1] Sanjay Kumar wrote:
> Hi,
> I am Sanjay Kumar and wants to write my own file
> system on Linux. I have almost written the code.
> But,now i have a problem while writing the code
> for "mkfs" for my filesystem.
>
> Problem Summary : I need the size of the block device
> in bytes on which my file system will be created.
> Actually, there is a feild in the super block, needs
> the total no of blocks on the device while while
> creating the filesystem. So, Can you Plz. help me out
> of this problem.
>
You make an ioctl() function for your file-system that returns
the block-size that you selected when you designed the system.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about
it.
^ permalink raw reply
* Re: Re: pci-skeleton duplex check
From: Mark H. Wood @ 2002-12-17 14:35 UTC (permalink / raw)
To: Linux kernel list
As if this wasn't contentious enough already, let me throw out something
for your consideration.
Q: When are *developers* most in need of stable models?
A: During development.
There's a fundamental problem here. Developers want complete freedom to
change their own models whenever they feel the need, yet the models on
which they depend must remain stable if their development is to continue
without interruption and they get snarly when those models change.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".
^ permalink raw reply
* Re: How to get the size of the block device ???? (Important)
From: Richard B. Johnson @ 2002-12-17 14:36 UTC (permalink / raw)
To: Sanjay Kumar; +Cc: linux-kernel, Matt_Domsch
In-Reply-To: <20021217142247.18564.qmail@web8206.mail.in.yahoo.com>
On Tue, 17 Dec 2002, [iso-8859-1] Sanjay Kumar wrote:
> Hi,
> I am Sanjay Kumar and wants to write my own file
> system on Linux. I have almost written the code.
> But,now i have a problem while writing the code
> for "mkfs" for my filesystem.
>
> Problem Summary : I need the size of the block device
> in bytes on which my file system will be created.
> Actually, there is a feild in the super block, needs
> the total no of blocks on the device while while
> creating the filesystem. So, Can you Plz. help me out
> of this problem.
>
You make an ioctl() function for your file-system that returns
the block-size that you selected when you designed the system.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Alan Cox @ 2002-12-17 15:12 UTC (permalink / raw)
To: Andre Hedrick
Cc: Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <Pine.LNX.4.10.10212170144030.31876-100000@master.linux-ide.org>
On Tue, 2002-12-17 at 09:45, Andre Hedrick wrote:
>
> Linus,
>
> Are you serious about moving of the banging we currently do on 0x80?
> If so, I have a P4 development board with leds to monitor all the lower io
> ports and can decode for you.
Different thing - int 0x80 syscall not i/o port 80. I've done I/O port
80 (its very easy), but requires we set up some udelay constants with an
initial safety value right at boot (which we should do - we udelay
before it is initialised)
^ permalink raw reply
* SCC and SMC to RS232 for MPC850
From: Donald MacArthur @ 2002-12-17 14:24 UTC (permalink / raw)
To: linuxppc-embedded
When enabling the SCC and SMC ports for RS232 on a MPC850, do you simply
need to connect the RX/TX/GND lines
to a RS232 line driver and enable the ports for UART in the kernel?
Is there a alternative/simple method for configuring an MPC850 to have four
RS232 serial ports?
Thank You
Donald MacArthur
dmacarth@ufl.edu
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] PCI: disable decoding while sizing BARs
From: Ivan Kokshaysky @ 2002-12-17 14:29 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Marcelo Tosatti, mj, linux-kernel
In-Reply-To: <200212161741.53287.bjorn_helgaas@hp.com>
On Mon, Dec 16, 2002 at 05:41:53PM -0700, Bjorn Helgaas wrote:
> + /* Disable I/O & memory decoding while we size the BARs. */
> + pci_read_config_word(dev, PCI_COMMAND, &cmd);
> + pci_write_config_word(dev, PCI_COMMAND,
> + cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY));
It's fatal for certain x86 northbridges, that's why the code was
removed 2 years ago.
Maybe it would be ok with this modification:
pci_read_config_word(dev, PCI_COMMAND, &cmd);
/* Don't touch northbridges or devices with devfn 0:0 */
if ((dev->class >> 8) != PCI_CLASS_BRIDGE_HOST && dev->devfn)
pci_write_config_word(dev, PCI_COMMAND,
cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY));
Ivan.
^ permalink raw reply
* WARNING: unexpected IO-APIC, please mail ....
From: Sebastian Frei @ 2002-12-17 14:19 UTC (permalink / raw)
To: linux-smp
Mainboard: MSI KT4V-L
256MB DDR333
BIOS Ver. 1.6
Linux version 2.5.52 (root@NOP) (gcc version 3.2) #1 Mon Dez 16 21:00:50 CET
2002
Video mode to be used for restore is fffd
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
255MB LOWMEM available.
found SMP MP-table at 000fb930
hm, page 000fb000 reserved twice.
hm, page 000fc000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 65520
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61424 pages, LIFO batch:14
HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 AMI ) @ 0x000fa980
ACPI: RSDT (v001 AMIINT VIA_K7 00000.00016) @ 0x0fff0000
ACPI: FADT (v001 AMIINT VIA_K7 00000.00017) @ 0x0fff0030
ACPI: MADT (v001 AMIINT VIA_K7 00000.00009) @ 0x0fff00c0
ACPI: DSDT (v001 VIA VIA_K7 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:6 APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0]
trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x3]
trigger[0x3])
Using ACPI (MADT) for SMP configuration information
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=L ro root=303
Initializing CPU#0
Detected 1733.291 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3416.06 BogoMIPS
Memory: 256232k/262080k available (1605k kernel code, 5144k reserved, 530k
data, 120k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: Before vendor init, caps: 0383fbff c1c3fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Machine check exception polling timer started.
CPU: AMD Athlon(tm) XP 2100+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23
not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 0 0 0 0 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 0 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 1 1 0 1 0 1 1 71
0a 001 01 0 0 0 0 0 1 1 79
0b 001 01 0 0 0 0 0 1 1 81
0c 001 01 0 0 0 0 0 1 1 89
0d 001 01 0 0 0 0 0 1 1 91
0e 001 01 0 0 0 0 0 1 1 99
0f 001 01 0 0 0 0 0 1 1 A1
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1733.0100 MHz.
..... host bus clock speed is 266.0630 MHz.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mtrr: v2.0 (20020519)
device class 'cpu': registering
device class cpu: adding driver system:cpu
PCI: Using configuration type 1
device class cpu: adding device CPU 0
interfaces: adding device CPU 0
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]: 1 bvecs: 256 entries (12 bytes)
biovec pool[1]: 4 bvecs: 256 entries (48 bytes)
biovec pool[2]: 16 bvecs: 256 entries (192 bytes)
biovec pool[3]: 64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20021212
ACPI-0263: *** Info: GPE Block0 defined as GPE0 to GPE15
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.93 (c) Adam Belay
PnPBIOS: Found PnP BIOS installation structure at 0xc00f79a0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x686b, dseg 0xf0000
PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver
block request queues:
128 requests per read queue
128 requests per write queue
8 requests per batch
enter congestion at 31
exit congestion at 33
SCSI subsystem driver Revision: 1.00
device class 'scsi-host': registering
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16)
00:00:01[A] -> 2-16 -> IRQ 16
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17)
00:00:01[B] -> 2-17 -> IRQ 17
IOAPIC[0]: Set PCI routing entry (2-22 -> 0xb9 -> IRQ 22)
00:00:11[C] -> 2-22 -> IRQ 22
Pin 2-16 already programmed
Pin 2-17 already programmed
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xc1 -> IRQ 18)
00:00:05[C] -> 2-18 -> IRQ 18
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc9 -> IRQ 19)
00:00:05[D] -> 2-19 -> IRQ 19
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-18 already programmed
Pin 2-16 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
IOAPIC[0]: Set PCI routing entry (2-21 -> 0xd1 -> IRQ 21)
00:00:10[A] -> 2-21 -> IRQ 21
Pin 2-21 already programmed
Pin 2-21 already programmed
Pin 2-21 already programmed
IOAPIC[0]: Set PCI routing entry (2-23 -> 0xd9 -> IRQ 23)
00:00:12[A] -> 2-23 -> IRQ 23
Pin 2-18 already programmed
ACPI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
aio_setup: sizeof(struct page) = 40
devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
PCI: Via IRQ fixup for 00:10.0, from 11 to 5
PCI: Via IRQ fixup for 00:10.1, from 10 to 5
PCI: Via IRQ fixup for 00:10.2, from 3 to 5
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Processor [CPU1] (supports C1, 16 throttling states)
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
tts/0 at I/O 0x3f8 (irq = 4) is a 16550A
pty: 256 Unix98 ptys configured
Linux agpgart interface v1.0 (c) Dave Jones
agpgart: Detected VIA Apollo Pro KT400 chipset
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: AGP aperture is 128M @ 0xe0000000
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
via-rhine.c:v1.10-LK1.1.15 November-22-2002 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
eth0: VIA VT6102 Rhine-II at 0xdfffee00, 00:10:dc:a6:b2:44, IRQ 23.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 41e1.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:11.1
ACPI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
hda: IC35L080AVVA07-0, ATA DISK drive
hda: DMA disabled
hda: bad special flag: 0x03
hda: tagged command queueing enabled, command queue depth 32
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: host protected area => 1
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=159560/16/63,
UDMA(100)
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
scsi HBA driver <NULL> didn't set max_sectors, please fix the template
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec 2940 Ultra SCSI adapter>
aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs
(scsi0:A:1): 20.000MB/s transfers (20.000MHz, offset 7)
Vendor: YAMAHA Model: CRW2100S Rev: 1.0N
Type: CD-ROM ANSI SCSI revision: 02
(scsi0:A:2): 20.000MB/s transfers (20.000MHz, offset 15)
Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.05
Type: CD-ROM ANSI SCSI revision: 02
scsi HBA driver Qlogic ISP 1280/12160 didn't set max_sectors, please fix the
template
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 1, lun 0
sr1: scsi-1 drive
Attached scsi CD-ROM sr1 at scsi0, channel 0, id 2, lun 0
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 120k freed
Adding 88348k swap on /dev/ide/host0/bus0/target0/lun0/part4. Priority:-1
extents:1
eth0: Setting full-duplex based on MII #1 link partner capability of 41e1.
^ permalink raw reply
* artic or artic II
From: John F Davis @ 2002-12-17 14:18 UTC (permalink / raw)
To: linuxppc-embedded
Hello
Which system are you folks using for development - artic or artic II?
Also, the artic II says to connect a serial port to get terminal access. I
do this before
I boot the box and I don't get anything on the minicom session. I am using
the db-9 serial connector on the base unit. My null modem cable works
with a different embedded system so I don't think its the cable or the
setup. Do you have
to hold down a button while booting or something?
JD
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* How to get the size of the block device ???? (Important)
From: Sanjay Kumar @ 2002-12-17 14:22 UTC (permalink / raw)
To: linux-kernel; +Cc: Matt_Domsch
Hi,
I am Sanjay Kumar and wants to write my own file
system on Linux. I have almost written the code.
But,now i have a problem while writing the code
for "mkfs" for my filesystem.
Problem Summary : I need the size of the block device
in bytes on which my file system will be created.
Actually, there is a feild in the super block, needs
the total no of blocks on the device while while
creating the filesystem. So, Can you Plz. help me out
of this problem.
I got your email id from :
http://lwn.net/2001/0906/a/last-sector.php3
Sanjay Kumar.
M.C.A.,
Univeristy of Pune,
India.
________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
visit http://in.tv.yahoo.com
^ permalink raw reply
* IRQ config problem on MPC8245
From: "Callebaut, Benoît" @ 2002-12-17 14:08 UTC (permalink / raw)
To: linuxppc-embedded
> Hello,
I have on a custom board a little problem with the IRQ configuration.
> Our board is a custom board derived from a sandpoint board X3B with a
> MPC8245 without any peripheral (no extern bridge, no IRQ controller,...)
> except 2 MAC/PHY 82449 from Intel and run Montavista Linux 2.1 based on a
> 2.4.18 Kernel
> The Interrupt lines from the MAC/PHY are directly connected to the
> interrupts inputs pins of the EPIC on the MPC8245.
> The EPIC is well configured (IVPR0,IVPR1, PCTPR,GCR,...)
> The Linux distribution is also modified to take this in account.
> The interrupts are generated on the EPIC (seen with an osilloscope and a
> register dump ).
> The interrupt handler is never called. There is no jump the address
> 0X00000500 (external interrupt exception vector )
> We ask ourselves what is the problem. We have seen that the value of the
> MSR[EE] bit change sometimesand that the value of MSR[IP] is well on null.
>
I know that such an question must be asked to Montavista support but such a
thing is beyond the standard support of Montavista (ie free after buying
their product)
- - - - - - - DISCLAIMER - - - - - - - -
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this message and/or
attachments is strictly prohibited. The company accepts no liability for any
damage caused by any virus transmitted by this email. Furthermore, the
company does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays. If you have
received this message in error, please contact the sender and delete the
message. Thank you.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [Linux-ia64] Re: Use of __ia64_syscall() - syscall interface
From: Joel GUILLET @ 2002-12-17 14:00 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805572@msgid-missing>
On Mon, 16 Dec 2002, David Mosberger wrote:
> >>>>> On Mon, 16 Dec 2002 17:07:18 +0100 (NFT), Joel GUILLET <Joel.Guillet@bull.net> said:
>
> Joel> This doesn't compile on a Itanium. I got a "undefined
> Joel> reference to __ia64_syscall()"
>
> Please use the syscall() routine instead. The stuff in unistd.h is
> for kernel-use only.
>
> --david
>
Thanks for your reply.
Actually, I had seen before some (lots of) mails (many from you) that
recommands the use of the syscall() interface, but I mis-understood
the message...
The problem is that I got some problems to find documentation about this
interface and made a mix between the kernel and the glibc interfaces.
(I finally found some in glibc/manual/libc.info-43 )
I can see clearly now. (Thanks for help)
So, as I found how to compile my program, I just send here the way
I used the interface, just in case someone would need it. (even, if it's
not the purpose of that mail-list).
***************************************
#ifndef __NR_sched_setaffinity
#ifndef _AFFINITY_H
#define _AFFINITY_H
#if defined(__ia64__)
#define __NR_sched_setaffinity 1231
#define __NR_sched_getaffinity 1232
#endif
#define sched_setaffinity(arg1, arg2, arg3) syscall(__NR_sched_setaffinity, arg1, arg2, arg3)
#define sched_getaffinity(arg1, arg2, arg3) syscall(__NR_sched_getaffinity, arg1, arg2, arg3)
#endif /* __NR_sched_setaffinity */
#endif /* _AFFINITY_H */
***************************************
(...and then just use directly sched_setaffinity in your program !)
Is that clean ?
----------------
** Joel **
^ permalink raw reply
* Re: how to forward packets to another gateway, if i'm one
From: Marcello Scacchetti @ 2002-12-17 14:00 UTC (permalink / raw)
To: Saulius Menkevicius; +Cc: netfilter@lists.netfilter.org
In-Reply-To: <ISPFE7vXn10A5fpk965000657df@mail.takas.lt>
Hi Saulius,
i think your solution is to use advanced kernel routing options using
the ip tool. This will allow you to use source based routing. route
command allows only setup destination based routes.
I think that http://lartc.org/ will come really in help to you, look for
Linux Advanced Routing & Traffic Control HOWTO.
Hope this helps,
Marcello
Il ven, 2002-12-06 alle 18:28, Saulius Menkevicius ha scritto:
> Hi,
> I've spend some time searching Google on the topic, however
> eventually gave up. So..
>
> Is there any way of forwarding packets to another gateway, which,
> besides, is on the same network. Say, I'm on IP 10.0.0.2, and I act
> as a gateway (ADSL, really) for a number of machines on the same LAN.
> And there's another such gateway, hooked to another ADSL, which
> handles connections for another bunch of machines. Essentially the
> hosts 10.0.0.1 and 10.0.0.2 are identic and perform the same
> function.
>
> Now, I want to make some traffic that comes from some client and
> that should go through gateway 10.0.0.1 to be forwarded to 10.0.0.2
> (without any changes). The need is to make the forwarding transparent
> to both 10.0.0.2 and the client.
>
> So it's the way I suppose it should be done:
> a) No changes to be made 10.0.0.2's firewalling rules (in fact, it
> runs FreeBSD);
> b) Make 10.0.0.1 to forward them to 10.0.0.2 transparently.
>
> _This_is_the_culprit_. I don't know how to make them (packets) go
> that way. DNAT/SNAT doesn't suit, neither does REDIRECT, as they
> modify packets they filter.
>
> In FreeBSD, there's ipfw rule fwd, e.g. if 10.0.0.1 ran bsd, i'd
> type "ipfw add fwd 10.0.0.2 ip from some_client to any". I'm looking
> for the a way on how to make the same effect on Linux/iptables.
> Wrote to much of blurb. Guess I didn't mess it up too much :)
>
> Thanks.
--
Marcello Scacchetti <marcello.scacchetti@nextrem.it>
^ permalink raw reply
* Re: compute_return_epc
From: Maciej W. Rozycki @ 2002-12-17 13:54 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20021217134333.A26119@linux-mips.org>
On Tue, 17 Dec 2002, Ralf Baechle wrote:
> So I'd like to apply the following patch which limits the use of
> compute_return_epc to those cases where we actually did some sort of
> instruction emulation. Comments?
Ah, finally! Thanks for offloading the task from me. ;-)
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Via 8233 flooding of errors [2.4-ac]
From: Alan Cox @ 2002-12-17 14:41 UTC (permalink / raw)
To: Nathaniel Russell; +Cc: alan, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212170636420.1698-200000@reddog.example.net>
On Tue, 2002-12-17 at 11:41, Nathaniel Russell wrote:
> Hello
> When i play 3 or more songs in a row i get the error message of
> drained playback and my audio just shuts off until i exit the mp3 program
> and reload it. Every 3rd song though it stops playing. And plus once in
> awhile i get a Assertion failed message. Help please....
> Nathaniel
> Assertion failed! chan->is_active == sg_active(chan->iobase),via82cxxx_audio.c,via_chan_maybe_start,line=1347
> via_audio: ignoring drain playback error -512
> [SNIPED]
I need to look at the assertion - somehow the chip is being stopped when
it should not have been. The ignoring drain playback error one is over
paranoia in the driver and quite legal (you hit ^C is what made that
second moan appear)
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-17 13:39 UTC (permalink / raw)
To: Jun Sun; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20021216124009.D10178@mvista.com>
On Mon, 16 Dec 2002, Jun Sun wrote:
> > > > OCW3 defaults to IRR in our setup (as it does for the chip itself after
> > > > writing ICWs) -- you need to select ISR explicitly before reading and
> > > > reset it afterwards to avoid surprises. Unless we change the default for
> > > > MIPS, which seems feasible -- we don't have to handle i386 oddities like
> > > > I/O APICs and weird chipset bugs. And we avoid the need to grab a
> > > > spinlock here. Alpha went this path.
>
> I actually meant to read IRR.
So the IRQ isn't ACKed within i8259As at this point -- I see. Anyway you
named your variable "isr", so it's at least confusing.
> I had the code for a while. I remembered I was reading a i8259 programming
> guide which recommands this method (perhaps for that MIPS board, which should
> generally apply to other MIPS boards.). The idea is to read IRR to figure
> out which interrupt you want to service and directly ack it and mask it.
The idea is mostly OK, although I'd do it differently -- see below. In
addition to derivatives I recommend reading the Intel's i8259A original
datasheet.
> This style fits more or less what we are doing with the rest of IRQ handling.
But remember the i8259A is alien to MIPS systems -- it was designed with
i8080/i8086 processors in mind. Specifically the way you handle it now
(no ACK for i8259As) breaks badly with edge-triggered interrupts.
> > Even if we needed do_slow_gettimeoffset(),
>
> No MIPS boards are using do_slow_gettimeoffset(). We really should get
> rid of it.
I know none does at the moment. But are you sure there is no system that
would need it and might be supported one day?
> > BTW, I thought on the code a bit and I discovered a few potential
> > problems due to races. Handling them depends on the way acks are sent to
> > i8259s -- Jun, could you please elaborate?
>
> I am not sure which part you are referring to. The dispatch_i8259_irq() itself
> is called from the first-level interrupt handling routine (assembly or in C),
> running with interrupt disabled.
I thought an IRQ is already ACKed within i8259As. Then you could have a
race with interrupt masking if an IRQ was masked just at the moment it
would be ACKed.
> When you decide to service an i8259 IRQ, you move on to call do_IRQ(), still
> with interrupt disabled. Pretty early in do_IRQ() we will do an ACK which will
> clear the bit in IRR, before possibly later we turn on interrupt again.
The i8259A doesn't work this way. With your proposed code the IRR is
never cleared (which is a problem for edge-triggered interrupts -- such an
interrupt gets signalled again once it's unmasked, until deasserted by a
device). The i8259A only clears a bit in the IRR when it receives an ACK
(it then copies the bit to the corresponding bit of the ISR) or when an
interrupt goes away (a device deasserts it).
I understand you may be confused by the Linux nomenclature -- for Linux
an ACK is what for the i8259A an EOI is (and mask_and_ack_8259A() does
send EOIs to the chips under the assumption the causing IRQ is already
ACKed -- see the code). There is no Linux name for what the i8259A calls
an ACK as Linux basically never sends ACKs to i8259As, because interrupts
arriving from them are ACKed by hardware by the means of INTA cycles
(which assert the INTA# lines of i8259As). For the i386 there is actually
an exception for the NMI watchdog running in specific obscure
configurations involving an i82489DX discrete APIC where an explicit ACK
is sent by Linux to the master i8259A to deassert the NMI -- can you find
it? ;-)
Here is an example (untested) code that I would recommend. It sends
explicit ACKs to the i8259As, which has the following advantages:
- the priority resolver of the i8259A is respected -- the settings of FNM,
EFNM (sort-of), rotating and SMM are obeyed,
- you get the IRQ number directly out of the i8259As,
- edge-triggered interrupts are handled properly,
- you don't have to mess with the mask.
asmlinkage void dispatch_i8259_irq(struct pt_regs *regs)
{
int irq, real;
spin_lock(&i8259A_lock);
outb(0x0c, 0x20);
iob();
/* ACK the IRQ (master). */
irq = inb(0x20);
real = (irq & 0x80);
irq &= 0x7;
if (!real)
goto spurious_master;
if (irq == 2) {
outb(0x0c, 0xa0);
iob();
/* ACK the IRQ (slave). */
irq = inb(0xa0);
real = (irq & 0x80);
irq = (irq & 0x7) + 8;
if (!real)
goto spurious_slave;
}
spin_unlock(&i8259A_lock);
do_IRQ(irq, regs);
return;
spurious_slave:
/* IRQ 2 was ACKed in the master; send an EOI to clear it. */
outb(0x62, 0x20);
iob();
spurious_master:
spin_unlock(&i8259A_lock);
printk("spurious 8259A interrupt: IRQ%d.\n", irq);
atomic_inc(&irq_err_count);
}
Does it work for you? And what do you think of it?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: kmalloc and startup process
From: Pantelis Antoniou @ 2002-12-17 13:40 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLKEODFIAA.joakim.tjernlund@lumentis.se>
Joakim Tjernlund wrote:
>Don't know when it's safe to call kmalloc, but maybe you
>should avoid kmalloc? Is it possible to use
>kmalloc when the microcode(8xx_io/micropatch.c) is loaded?
>
> Jocke
>
I fixed the problem via another way.
At startup I use a statically allocated area, or
the bootmem allocated page.
The kmalloc is used only when a request for memory
cannot be satisfied by this memory.
I will probably post the patch for the hostmem today,
followed tommorow by the patch for the dpmem.
Stay tuned.
>>
>>Hi
>>
>>I'm hacking now the 8xx hostalloc and dpalloc stuff,
>>and I have a a question.
>>
>>At what point in the startup process is it OK to call
>>kmalloc?
>>
>>I don't think it is safe at the setup_arch point.
>>
>>Is this correct?
>>
>>Thanks
>>
>>--
>>Pantelis Antoniou
>>INTRACOM S.A. Greece
>>
>>
>>
>>
>>
>
>
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: .reginfo and .mdebug section
From: Ralf Baechle @ 2002-12-17 13:39 UTC (permalink / raw)
To: Long Li; +Cc: linux-mips
In-Reply-To: <20021217084303.20121.qmail@web40407.mail.yahoo.com>
On Tue, Dec 17, 2002 at 12:43:03AM -0800, Long Li wrote:
> 1. I tried to compile some c code targetting mips4k,
> which is 32-bit ISA. However, the map file tells me
> that the compiled code are 64-bit, since the address
> are 64-bit.
>
> 2. When I compiled the c code, I found in the mapfile
> that there are some sections called .reginfo and
> .mdebug. What are those sections? I would like to get
> rid of them. However, they still exists even if I
> deleted the '-g' option for gcc. Is there a way I can
> avoid the .reginfo and .mdebug sections?
.reginfo is MIPS ABI mandated brain damage described the register usage of
a given object or shared object. I know of nothing that actually is using
these sections. It's always just 24 bytes so not really worth alot of fuzz
though. With some binutils versions you can remove this section with
objcopy --remove-section=.reginfo. Some binutils version however will just
create a new .reginfo section during objcopy so with those this won't work.
.mdebug is the MIPS ABI mdebug stuff, debug information. You should be
able to get rid of those with -g, at least my tools here don't create it
by default.
Ralf
^ 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.