NEC IDE DVD writer breaks when writing with DMA; is this normal?
I've recently added an NEC DVD writer (ND-6450A) to my ThinkPad A30.
It breaks badly if I try to write with it with cdrecord or
dvd+rw-tools when DMA is on. With DMA off, it works, but it uses a
heck of a lot of CPU time -- the whole laptop is really really doggy.
Is this the kind of thing I should just expect from DVD writers? Or
is this a good candidate for some driver work to adjust for the quirks
of this device?
System info follows:
[boot log]
kernel: ICH3M: chipset revision 1
kernel: ICH3M: not 100%% native mode: will probe irqs later
kernel: ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
kernel: ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio
kernel: hda: HTS548080M9AT00, ATA DISK drive
kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
kernel: hdc: _NEC DVD+/-RW ND-6450A, ATAPI CD/DVD-ROM drive
kernel: ide1 at 0x170-0x177,0x376 on irq 15
kernel: hda: max request size: 1024KiB
kernel: hda: 156301488 sectors (80026 MB) w/7877KiB Cache, CHS=16383/255/63,
UDMA(100)
kernel: hda: hda1 hda2 < hda5 hda6 hda7 hda8 >
[error log]
Feb 18 12:13:00 kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2
cdda tray
Feb 18 12:13:00 kernel: Uniform CD-ROM driver Revision: 3.20
Feb 18 12:13:00 kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
[...]
Feb 18 12:19:46 kernel: hdc: DMA timeout retry
Feb 18 12:19:46 kernel: hdc: timeout waiting for DMA
Feb 18 12:19:46 kernel: hdc: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: ide-scsi: No active request in idescsi_eh_reset
Feb 18 12:19:46 kernel: scsi: Device offlined - not ready after error recovery:
host 0 channel 0 id 0 lun 0
Feb 18 12:19:46 kernel: SCSI error : <0 0 0 0> return code = 0x2
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
[hdparm -i]
Model=_NEC DVD+/-RW ND-6450A, FwRev=2.36, SerialNo=
Config={ Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
AdvancedPM=no
[lspci -v]
:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01) (prog-if 8a
[Master SecP PriP])
Subsystem: IBM ThinkPad A/T/X Series
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at
I/O ports at
I/O ports at
I/O ports at
I/O ports at 1860 [size=16]
Memory at 2800 (32-bit, non-prefetchable) [size=1K]
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
Open Source is not an excuse to write fun code
then leave the actual work to others.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NEC IDE DVD writer breaks when writing with DMA; is this normal?
I've recently added an NEC DVD writer (ND-6450A) to my ThinkPad A30.
It breaks badly if I try to write with it with cdrecord or
dvd+rw-tools when DMA is on. With DMA off, it works, but it uses a
heck of a lot of CPU time -- the whole laptop is really really doggy.
Is this the kind of thing I should just expect from DVD writers? Or
is this a good candidate for some driver work to adjust for the quirks
of this device?
System info follows:
[boot log]
kernel: ICH3M: chipset revision 1
kernel: ICH3M: not 100%% native mode: will probe irqs later
kernel: ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
kernel: ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio
kernel: hda: HTS548080M9AT00, ATA DISK drive
kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
kernel: hdc: _NEC DVD+/-RW ND-6450A, ATAPI CD/DVD-ROM drive
kernel: ide1 at 0x170-0x177,0x376 on irq 15
kernel: hda: max request size: 1024KiB
kernel: hda: 156301488 sectors (80026 MB) w/7877KiB Cache, CHS=16383/255/63,
UDMA(100)
kernel: hda: hda1 hda2 hda5 hda6 hda7 hda8
[error log]
Feb 18 12:13:00 kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2
cdda tray
Feb 18 12:13:00 kernel: Uniform CD-ROM driver Revision: 3.20
Feb 18 12:13:00 kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
[...]
Feb 18 12:19:46 kernel: hdc: DMA timeout retry
Feb 18 12:19:46 kernel: hdc: timeout waiting for DMA
Feb 18 12:19:46 kernel: hdc: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: ide-scsi: No active request in idescsi_eh_reset
Feb 18 12:19:46 kernel: scsi: Device offlined - not ready after error recovery:
host 0 channel 0 id 0 lun 0
Feb 18 12:19:46 kernel: SCSI error : 0 0 0 0 return code = 0x2
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
[hdparm -i]
Model=_NEC DVD+/-RW ND-6450A, FwRev=2.36, SerialNo=
Config={ Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
AdvancedPM=no
[lspci -v]
:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01) (prog-if 8a
[Master SecP PriP])
Subsystem: IBM ThinkPad A/T/X Series
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at ignored
I/O ports at ignored
I/O ports at ignored
I/O ports at ignored
I/O ports at 1860 [size=16]
Memory at 2800 (32-bit, non-prefetchable) [size=1K]
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
Open Source is not an excuse to write fun code
then leave the actual work to others.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] restore skb_copy_datagram, removed from 2.6.11-rc2, breaking VMWare
Those of you who are using VMWare 4.5 will find that 2.6.11-rc2
removes the public function "skb_copy_datagram", breaking VMWare
(and any other module using that interface *sigh*).
The attached patch restores the (little harmless wrapper) function.
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"What I cannot create, I do not understand." - Richard Feynman
--- x/include/linux/skbuff.h.old2005-01-22 10:03:55.0 -0500
+++ y/include/linux/skbuff.h2005-01-22 10:42:33.0 -0500
@@ -1087,4 +1087,6 @@
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
--- x/net/core/datagram.c.old 2005-01-22 10:03:56.0 -0500
+++ y/net/core/datagram.c 2005-01-22 10:43:40.0 -0500
@@ -200,4 +200,17 @@
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, , size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
@@ -478,4 +491,5 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
[PATCH] restore skb_copy_datagram, removed from 2.6.11-rc2, breaking VMWare
Those of you who are using VMWare 4.5 will find that 2.6.11-rc2
removes the public function skb_copy_datagram, breaking VMWare
(and any other module using that interface *sigh*).
The attached patch restores the (little harmless wrapper) function.
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
What I cannot create, I do not understand. - Richard Feynman
--- x/include/linux/skbuff.h.old2005-01-22 10:03:55.0 -0500
+++ y/include/linux/skbuff.h2005-01-22 10:42:33.0 -0500
@@ -1087,4 +1087,6 @@
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
--- x/net/core/datagram.c.old 2005-01-22 10:03:56.0 -0500
+++ y/net/core/datagram.c 2005-01-22 10:43:40.0 -0500
@@ -200,4 +200,17 @@
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, iov, size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
@@ -478,4 +491,5 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: > Chip: > > Wouldn't it be better just to *try* ioctls and see which ones work and > > which ones don't? > > 1. We have overlaps We all agree that overlaps need to be eliminated over time. In the meantime, as a coping strategy: I'll bet you that for any two given device classes, there is at least one ioctl that works on only one of them. (I'm only talking about an interim workaround! Calm down! Put down those bats!) > 2. I've seen code where people play clever ioctl tricks to deduce a > device type and it ends up looking like one of those chemistry > identification charts (hopefully minus do you see smoke ?) I don't mean to suggest that ioctls be used to deduce device types (except in the case of overlapping ioctl numbers, which shouldn't be all *that* common (I hope)). I mean to suggest that the question "What device type are you?" usually shouldn't even be asked! If you want to do X to the device on fd, just call ioctl(fd, X, ...). Either it works or it doesn't. I realize that overlapping ioctls throw a monkey wrench into this world view. Is it a bigger wrench than the wrenching pain that we'll have to live through to make device identification reliable? Depends on how many ioctls overlap, and how easily we could make them stop overlapping. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to H. Peter Anvin: > A device can inherently belong to multiple device classes, and it > really should be thought of as such. And then there are layering technologies like LVM and loopback. They should be included in a discovery, but if you limit yourself to one "device type", there's no place for them. > For example a disk may belong, at the same time, to the "scsi", > "disk" and "scsi-disk" device classes [...] True, but in a sane system, "scsi" + "disk" implies "scsi-disk". -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to James Simmons: > Graphics cards are the same way. Especially high end ones. They have pipes > as well. For low end cards you can think of them as single pipeline cards > with one pipe. It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use write(). It's a natural way to feed pipelines. But no, it's a raft of ioctl() calls. *sigh* -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Johannes Erdfelt: > I had always made the assumption that sockets were created because you > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable > to have a file for every possible IP address/port you can communicate > with. I think you're right on both counts, but I'm sure you'll agree that just because some undergrad at Berkeley did something a certain way 20 years ago doesn't mean we have to follow it blindly. :-) IIRC, Plan 9 allocate TCP connections rather like Linux allocates ptys. When we allocate a pty we don't have to say what program we're going to connect to; we allocate it and then use it as we like. Similarly, in Plan 9 you allocate a TCP connection without having to say who you're going to connect to. The main differences between the Plan 9 approach and the socket approach are: 1. Plan 9 connections are filesystem entities (like our ptys) 2. Control is done via read/write on a separate control channel, which is *also* a filesystem entity. USB could use a similar approach. And since each client would allocate a new connection entity for its own use -- even if it's going to connect to a device that someone else is already connected to -- permissions becomes quite simple to manage. Come to think of it, the mechanism I'm describing could address all hotpluggable devices.... -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Linus Torvalds: > I don't see why we couldn't expose the "driver name" for any file > descriptor. Is it wise to assume that there is only one such name for *any* file descriptor? -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alexander Viro: > On Tue, 15 May 2001, James Simmons wrote: > > I would use write except we use write to draw into the framebuffer. If I > > write to the framebuffer with that data the only thing that will happen is > > I will get pretty colors on my screen. > > Yes. And we also use write to send data to printer. So what? Nobody makes > you use the same file. You're talking about /dev/fb0 vs. /dev/fb0ctl, right? Would that driver authors routinely used such clean designs. PS: No, readers, AFAIK, there is no such thing as /dev/fb0ctl. Yet. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: > Given a file handle 'X' how do I find out what ioctl groups I should > apply to it. Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? This ioctl situation reminds me of how novice programmers assume that they have to call access() or stat() and check a file for existence and readability before calling open(). But that's just stupid when you think about it, because if the file isn't there and the open() fails, that's OK! Failures are not fatal. Similarly, ioctl failures are not fatal. Just Try Them. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: Given a file handle 'X' how do I find out what ioctl groups I should apply to it. Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? This ioctl situation reminds me of how novice programmers assume that they have to call access() or stat() and check a file for existence and readability before calling open(). But that's just stupid when you think about it, because if the file isn't there and the open() fails, that's OK! Failures are not fatal. Similarly, ioctl failures are not fatal. Just Try Them. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alexander Viro: On Tue, 15 May 2001, James Simmons wrote: I would use write except we use write to draw into the framebuffer. If I write to the framebuffer with that data the only thing that will happen is I will get pretty colors on my screen. Yes. And we also use write to send data to printer. So what? Nobody makes you use the same file. You're talking about /dev/fb0 vs. /dev/fb0ctl, right? Would that driver authors routinely used such clean designs. PS: No, readers, AFAIK, there is no such thing as /dev/fb0ctl. Yet. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Linus Torvalds: I don't see why we couldn't expose the driver name for any file descriptor. Is it wise to assume that there is only one such name for *any* file descriptor? -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to James Simmons: Graphics cards are the same way. Especially high end ones. They have pipes as well. For low end cards you can think of them as single pipeline cards with one pipe. It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use write(). It's a natural way to feed pipelines. But no, it's a raft of ioctl() calls. *sigh* -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Johannes Erdfelt: I had always made the assumption that sockets were created because you couldn't easily map IPv4 semantics onto filesystems. It's unreasonable to have a file for every possible IP address/port you can communicate with. I think you're right on both counts, but I'm sure you'll agree that just because some undergrad at Berkeley did something a certain way 20 years ago doesn't mean we have to follow it blindly. :-) IIRC, Plan 9 allocate TCP connections rather like Linux allocates ptys. When we allocate a pty we don't have to say what program we're going to connect to; we allocate it and then use it as we like. Similarly, in Plan 9 you allocate a TCP connection without having to say who you're going to connect to. The main differences between the Plan 9 approach and the socket approach are: 1. Plan 9 connections are filesystem entities (like our ptys) 2. Control is done via read/write on a separate control channel, which is *also* a filesystem entity. USB could use a similar approach. And since each client would allocate a new connection entity for its own use -- even if it's going to connect to a device that someone else is already connected to -- permissions becomes quite simple to manage. Come to think of it, the mechanism I'm describing could address all hotpluggable devices -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to H. Peter Anvin: A device can inherently belong to multiple device classes, and it really should be thought of as such. And then there are layering technologies like LVM and loopback. They should be included in a discovery, but if you limit yourself to one device type, there's no place for them. For example a disk may belong, at the same time, to the scsi, disk and scsi-disk device classes [...] True, but in a sane system, scsi + disk implies scsi-disk. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: Chip: Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? 1. We have overlaps We all agree that overlaps need to be eliminated over time. In the meantime, as a coping strategy: I'll bet you that for any two given device classes, there is at least one ioctl that works on only one of them. (I'm only talking about an interim workaround! Calm down! Put down those bats!) 2. I've seen code where people play clever ioctl tricks to deduce a device type and it ends up looking like one of those chemistry identification charts (hopefully minus do you see smoke ?) I don't mean to suggest that ioctls be used to deduce device types (except in the case of overlapping ioctl numbers, which shouldn't be all *that* common (I hope)). I mean to suggest that the question What device type are you? usually shouldn't even be asked! If you want to do X to the device on fd, just call ioctl(fd, X, ...). Either it works or it doesn't. I realize that overlapping ioctls throw a monkey wrench into this world view. Is it a bigger wrench than the wrenching pain that we'll have to live through to make device identification reliable? Depends on how many ioctls overlap, and how easily we could make them stop overlapping. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Your message to linux-lvm awaits moderator approval
Rik van Riel writes: >[...] Andreas' patches got dropped over and over again and comments >on the LVM code got refused by the moderators at Sistina ... "The Net interprets censorship as damage and routes around it." -- John Gilmore -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Your message to linux-lvm awaits moderator approval
Rik van Riel writes: [...] Andreas' patches got dropped over and over again and comments on the LVM code got refused by the moderators at Sistina ... "The Net interprets censorship as damage and routes around it." -- John Gilmore -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
In article <[EMAIL PROTECTED]> you write: >On Fri, 13 Apr 2001, Nate Eldredge wrote: >> (32 bytes is the size of a cache line.) A memory tester might be >> something to try (I wrote a simple program that seemed to show the >> error better than memtest86; can send it if desired.) > >Already tried that... this system has passed some 20 hours running >memtest86... I suggest you try Cerberus: https://sourceforge.net/projects/va-ctcs/ which will viciously beat your system to within an inch of its life. If you have any motherboard problems, they're more likely to show up with Cerberus than with a simple memtest. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
In article [EMAIL PROTECTED] you write: On Fri, 13 Apr 2001, Nate Eldredge wrote: (32 bytes is the size of a cache line.) A memory tester might be something to try (I wrote a simple program that seemed to show the error better than memtest86; can send it if desired.) Already tried that... this system has passed some 20 hours running memtest86... I suggest you try Cerberus: https://sourceforge.net/projects/va-ctcs/ which will viciously beat your system to within an inch of its life. If you have any motherboard problems, they're more likely to show up with Cerberus than with a simple memtest. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
According to [EMAIL PROTECTED]:
>[EMAIL PROTECTED] (Chip Salzenberg) wrote:
>>Why not have a kernel thread and use standard RPC techniques like
>>sockets? Then you'd not have to invent anything unimportant like
>>Yet Another IPC Technique.
>
>kerneld (kmod's late unlamented predecessor) used to use Unix sockets
>to communicate from the kernel to the daemon. It forced everybody to
>link Unix sockets into the kernel but there are some people out there
>who want to use it as a module. Also the kernel code for communicating
>with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.
I see.
On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server. Thus, the question of how clients know which response is for
them is trivially solved. ('Server' would in this case be the JFS
kernel thread.)
Sockets are apparently not the right way to go about getting
transaction support for kernel threads.
AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings. With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.
I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
According to [EMAIL PROTECTED]:
[EMAIL PROTECTED] (Chip Salzenberg) wrote:
Why not have a kernel thread and use standard RPC techniques like
sockets? Then you'd not have to invent anything unimportant like
Yet Another IPC Technique.
kerneld (kmod's late unlamented predecessor) used to use Unix sockets
to communicate from the kernel to the daemon. It forced everybody to
link Unix sockets into the kernel but there are some people out there
who want to use it as a module. Also the kernel code for communicating
with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.
I see.
On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server. Thus, the question of how clients know which response is for
them is trivially solved. ('Server' would in this case be the JFS
kernel thread.)
Sockets are apparently not the right way to go about getting
transaction support for kernel threads.
AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings. With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.
I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TCP Vegas implementation for Linux
Our (VA's) kernel includes a Vegas patch: ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
In article <OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain> you write: >With ioctl, I can easily match a response of any kind to a request. I can >even return an English text message if I want to be friendly. But ioctl requires allocation of numbers. Ugly and hard to scale. Alex Viro's idea is cleaner, but still requires a fair amount of coding even for simple interfaces. Why not have a kernel thread and use standard RPC techniques like sockets? Then you'd not have to invent anything unimportant like Yet Another IPC Technique. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
In article OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain you write: With ioctl, I can easily match a response of any kind to a request. I can even return an English text message if I want to be friendly. But ioctl requires allocation of numbers. Ugly and hard to scale. Alex Viro's idea is cleaner, but still requires a fair amount of coding even for simple interfaces. Why not have a kernel thread and use standard RPC techniques like sockets? Then you'd not have to invent anything unimportant like Yet Another IPC Technique. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP Vegas implementation for Linux
Our (VA's) kernel includes a Vegas patch: ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remote Management (was Re: Alert on LAN)
According to Terje Malmedal: > I am aware of some motherboards where you can configure the BIOS via > RS232. What I want is some way to actually reset a machine that is > hung. That's possible with VACM-style management. It's not just for BIOS. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remote Management (was Re: Alert on LAN)
According to Terje Malmedal: I am aware of some motherboards where you can configure the BIOS via RS232. What I want is some way to actually reset a machine that is hung. That's possible with VACM-style management. It's not just for BIOS. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff -> hangup
Andre Hedrick writes: >On Thu, 15 Mar 2001, CODEZ wrote: >> ide_dmaproc: chipset supported ide_dma_timeout func only: 14 >> I have ASUS 440BX/F mb with intel PIIX4 chipset.. > >All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond >repair. Well, that may be so; but I get the same error -- *precisely* the same error! -- on an SiS motherboard that quite clearly lacks a PIIX4: # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev b1) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 11) 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 00:0b.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang] 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev a2) # lspci -v -s0:0 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) Flags: bus master, medium devsel, latency 32 Memory at e000 (32-bit, non-prefetchable) Capabilities: [c0] AGP version 2.0 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP]) Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step) Flags: bus master, fast devsel, latency 128, IRQ 14 I/O ports at e400 I/O ports at e000 I/O ports at d800 I/O ports at d400 I/O ports at d000 So... Any ideas? > I will pop a nasty patch to get you through the almost death, but it > is nasty and not the preferred unknow solution. I await your fugly patch with bated breath and baited fishook. -- Chip Salzenberga.k.a.<[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remote Management (was Re: Alert on LAN)
IBM says, as quoted by Terje Malmedal: > With the latest release, Alert on LAN 2 now extends IT > capabilities to remotely manage and control their > networked PCs: > > Remote system reboot upon report of a critical failure > Repair Operating System > Update BIOS image > Perform other diagnostic procedures OK, fine... but: Where are the authentication and authorization?! Surely I'm not the only person to see in this "Alert On LAN 2" the potential for a security disaster. I know I will never buy anything that supports AOL2 until its security features are openly documented and testable. > The feature I really need is to be able to reset the machine > remotely when Linux is hung. Some current PC motherboards support remote management via a serial line. Of course, you'll need software: The VA Cluster Manager (GPL'd - http://sourceforge.net/projects/vacm) can monitor and control any number of clients, limited only by the number of serial ports you can give it. VACM also includes optional client support for enhanced monitoring, e.g. of temperatures. I'm not sure which motherboards it supports, but I'm sure you can find current documentation. :-) Granted, this is not cheap. A VACM-style approach costs some money for the monitor computer, and some convenience for installing the serial lines; meanwhile, AOL2 promises to do it all over Ethernet. But with VACM, you can be sure that somebody has to log in to the monitor computer -- with security levels you control! -- before they can control or even monitor any connected clients. BTW, in the spirit of full disclosure: VACM is a product of VA Linux engineering, and I work for VA. But VACM is GPL'd and we don't charge for it, so I have little financial interest in seeing it used. I just *hate* it when people play fast & loose with my security. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remote Management (was Re: Alert on LAN)
IBM says, as quoted by Terje Malmedal: With the latest release, Alert on LAN 2 now extends IT capabilities to remotely manage and control their networked PCs: Remote system reboot upon report of a critical failure Repair Operating System Update BIOS image Perform other diagnostic procedures OK, fine... but: Where are the authentication and authorization?! Surely I'm not the only person to see in this "Alert On LAN 2" the potential for a security disaster. I know I will never buy anything that supports AOL2 until its security features are openly documented and testable. The feature I really need is to be able to reset the machine remotely when Linux is hung. Some current PC motherboards support remote management via a serial line. Of course, you'll need software: The VA Cluster Manager (GPL'd - http://sourceforge.net/projects/vacm) can monitor and control any number of clients, limited only by the number of serial ports you can give it. VACM also includes optional client support for enhanced monitoring, e.g. of temperatures. I'm not sure which motherboards it supports, but I'm sure you can find current documentation. :-) Granted, this is not cheap. A VACM-style approach costs some money for the monitor computer, and some convenience for installing the serial lines; meanwhile, AOL2 promises to do it all over Ethernet. But with VACM, you can be sure that somebody has to log in to the monitor computer -- with security levels you control! -- before they can control or even monitor any connected clients. BTW, in the spirit of full disclosure: VACM is a product of VA Linux engineering, and I work for VA. But VACM is GPL'd and we don't charge for it, so I have little financial interest in seeing it used. I just *hate* it when people play fast loose with my security. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff - hangup
Andre Hedrick writes: On Thu, 15 Mar 2001, CODEZ wrote: ide_dmaproc: chipset supported ide_dma_timeout func only: 14 I have ASUS 440BX/F mb with intel PIIX4 chipset.. All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond repair. Well, that may be so; but I get the same error -- *precisely* the same error! -- on an SiS motherboard that quite clearly lacks a PIIX4: # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev b1) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 11) 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 00:0b.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang] 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev a2) # lspci -v -s0:0 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) Flags: bus master, medium devsel, latency 32 Memory at e000 (32-bit, non-prefetchable) Capabilities: [c0] AGP version 2.0 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP]) Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step) Flags: bus master, fast devsel, latency 128, IRQ 14 I/O ports at e400 I/O ports at e000 I/O ports at d800 I/O ports at d400 I/O ports at d000 So... Any ideas? I will pop a nasty patch to get you through the almost death, but it is nasty and not the preferred unknow solution. I await your fugly patch with bated breath and baited fishook. -- Chip Salzenberga.k.a.[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi
With Andre's IDE subsystem, I found the below patch necessary to use
my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long
since I created this patch that I can't remember the detailed reasons
for the changes. But I knew them once. :-) And it works for me.
Reminder, this is against Andre Hedrick's 2.2 IDE subsystem.
Index: drivers/block/ide-tape.c
--- drivers/block/ide-tape.c.prev
+++ drivers/block/ide-tape.cTue Dec 5 01:17:32 2000
@@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr
static int idetape_flush_tape_buffers (ide_drive_t *drive)
{
+ idetape_tape_t *tape = drive->driver_data;
idetape_pc_t pc;
int rc;
+ if (tape->chrdev_direction != idetape_direction_write)
+ return 0;
idetape_create_write_filemark_cmd(drive, , 0);
if ((rc = idetape_queue_pc_tail (drive,)))
@@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i
if (tape->chrdev_direction == idetape_direction_none) {
MOD_INC_USE_COUNT;
+ if (tape->onstream) {
#if ONSTREAM_DEBUG
- if (tape->debug_level >= 6)
- printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in
idetape_chrdev_open-2\n");
+ if (tape->debug_level >= 6)
+ printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT"
+ " in idetape_chrdev_open-2\n");
#endif
- idetape_create_prevent_cmd(drive, , 1);
- if (!idetape_queue_pc_tail (drive,)) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
- tape->door_locked = DOOR_LOCKED;
+ idetape_create_prevent_cmd(drive, , 1);
+ if (!idetape_queue_pc_tail (drive,)) {
+ if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
+ tape->door_locked = DOOR_LOCKED;
+ }
}
idetape_analyze_headers(drive);
@@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc
(void) idetape_rewind_tape (drive);
if (tape->chrdev_direction == idetape_direction_none) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
- idetape_create_prevent_cmd(drive, , 0);
- if (!idetape_queue_pc_tail (drive,))
- tape->door_locked = DOOR_UNLOCKED;
- }
- MOD_DEC_USE_COUNT;
+ if (tape->onstream) {
+ if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
+ idetape_create_prevent_cmd(drive, , 0);
+ if (!idetape_queue_pc_tail (drive,))
+ tape->door_locked = DOOR_UNLOCKED;
+ }
#if ONSTREAM_DEBUG
- if (tape->debug_level >= 6)
- printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in
idetape_chrdev_release\n");
+ if (tape->debug_level >= 6)
+ printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT"
+ " in idetape_chrdev_release\n");
#endif
+ }
+ MOD_DEC_USE_COUNT;
}
clear_bit (IDETAPE_BUSY, >flags);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi
With Andre's IDE subsystem, I found the below patch necessary to use
my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long
since I created this patch that I can't remember the detailed reasons
for the changes. But I knew them once. :-) And it works for me.
Reminder, this is against Andre Hedrick's 2.2 IDE subsystem.
Index: drivers/block/ide-tape.c
--- drivers/block/ide-tape.c.prev
+++ drivers/block/ide-tape.cTue Dec 5 01:17:32 2000
@@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr
static int idetape_flush_tape_buffers (ide_drive_t *drive)
{
+ idetape_tape_t *tape = drive-driver_data;
idetape_pc_t pc;
int rc;
+ if (tape-chrdev_direction != idetape_direction_write)
+ return 0;
idetape_create_write_filemark_cmd(drive, pc, 0);
if ((rc = idetape_queue_pc_tail (drive,pc)))
@@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i
if (tape-chrdev_direction == idetape_direction_none) {
MOD_INC_USE_COUNT;
+ if (tape-onstream) {
#if ONSTREAM_DEBUG
- if (tape-debug_level = 6)
- printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in
idetape_chrdev_open-2\n");
+ if (tape-debug_level = 6)
+ printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT"
+ " in idetape_chrdev_open-2\n");
#endif
- idetape_create_prevent_cmd(drive, pc, 1);
- if (!idetape_queue_pc_tail (drive,pc)) {
- if (tape-door_locked != DOOR_EXPLICITLY_LOCKED)
- tape-door_locked = DOOR_LOCKED;
+ idetape_create_prevent_cmd(drive, pc, 1);
+ if (!idetape_queue_pc_tail (drive,pc)) {
+ if (tape-door_locked != DOOR_EXPLICITLY_LOCKED)
+ tape-door_locked = DOOR_LOCKED;
+ }
}
idetape_analyze_headers(drive);
@@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc
(void) idetape_rewind_tape (drive);
if (tape-chrdev_direction == idetape_direction_none) {
- if (tape-door_locked != DOOR_EXPLICITLY_LOCKED) {
- idetape_create_prevent_cmd(drive, pc, 0);
- if (!idetape_queue_pc_tail (drive,pc))
- tape-door_locked = DOOR_UNLOCKED;
- }
- MOD_DEC_USE_COUNT;
+ if (tape-onstream) {
+ if (tape-door_locked != DOOR_EXPLICITLY_LOCKED) {
+ idetape_create_prevent_cmd(drive, pc, 0);
+ if (!idetape_queue_pc_tail (drive,pc))
+ tape-door_locked = DOOR_UNLOCKED;
+ }
#if ONSTREAM_DEBUG
- if (tape-debug_level = 6)
- printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in
idetape_chrdev_release\n");
+ if (tape-debug_level = 6)
+ printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT"
+ " in idetape_chrdev_release\n");
#endif
+ }
+ MOD_DEC_USE_COUNT;
}
clear_bit (IDETAPE_BUSY, tape-flags);
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to J . A . Magallon: > Please, I think it would be much more useful a patch against the latest > 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried) > and the latest 2.4.1-ac14, that is what people experiments with. There's no end of versions that people use. Might I suggest that Justin imitate the maintainers of lm_sensors, and create a program (shell script, Perl program, whatever) that *creates* a patch against any given Linux source tree? Obviously it could break in the face of weird trees, but even minimal flexibility would save him a lot of work ... -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to J . A . Magallon: Please, I think it would be much more useful a patch against the latest 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried) and the latest 2.4.1-ac14, that is what people experiments with. There's no end of versions that people use. Might I suggest that Justin imitate the maintainers of lm_sensors, and create a program (shell script, Perl program, whatever) that *creates* a patch against any given Linux source tree? Obviously it could break in the face of weird trees, but even minimal flexibility would save him a lot of work ... -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to Matthew Jacob: > See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to Matthew Jacob: See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] inter_module_* backport to 2.2.18
arbitrary string to identify the data, must be unique
+ *
+ * Description: Check that the im_name has been registered, complain if
+ * it has not. For existing data, remove it from the
+ * inter_module_entry list.
+ */
+void inter_module_unregister(const char *im_name)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime;
+
+ spin_lock(_lock);
+ list_for_each(tmp, _list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ list_del(&(ime->list));
+ spin_unlock(_lock);
+ kfree(ime);
+ return;
+ }
+ }
+ spin_unlock(_lock);
+ if (kmalloc_failed) {
+ printk(KERN_ERR
+ "inter_module_unregister: no entry for '%s', "
+ "probably caused by previous kmalloc failure\n",
+ im_name);
+ return;
+ }
+ else {
+ /* Program logic error, fatal */
+ printk(KERN_ERR "inter_module_unregister: no entry for '%s'", im_name);
+ BUG();
+ }
+}
+
+/**
+ * inter_module_get - return arbitrary userdata from another module.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ *
+ * Description: If the im_name has not been registered, return NULL.
+ * Try to increment the use count on the owning module, if that fails
+ * then return NULL. Otherwise return the userdata.
+ */
+const void *inter_module_get(const char *im_name)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime;
+ const void *result = NULL;
+
+ spin_lock(_lock);
+ list_for_each(tmp, _list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ if (try_inc_mod_count(ime->owner))
+ result = ime->userdata;
+ break;
+ }
+ }
+ spin_unlock(_lock);
+ return(result);
+}
+
+/**
+ * inter_module_get_request - im get with automatic request_module.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ * @modname: module that is expected to register im_name
+ *
+ * Description: If inter_module_get fails, do request_module then retry.
+ */
+const void *inter_module_get_request(const char *im_name, const char *modname)
+{
+ const void *result = inter_module_get(im_name);
+ if (!result) {
+ request_module(modname);
+ result = inter_module_get(im_name);
+ }
+ return(result);
+}
+
+/**
+ * inter_module_put - release use of data from another module.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ *
+ * Description: If the im_name has not been registered, complain,
+ * otherwise decrement the use count on the owning module.
+ */
+void inter_module_put(const char *im_name)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime;
+
+ spin_lock(_lock);
+ list_for_each(tmp, _list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ if (ime->owner)
+ __MOD_DEC_USE_COUNT(ime->owner);
+ spin_unlock(_lock);
+ return;
+ }
+ }
+ spin_unlock(_lock);
+ printk(KERN_ERR "inter_module_put: no entry for '%s'", im_name);
+ BUG();
+}
+
+
+#if defined(CONFIG_MODULES)/* The rest of the source */
+
static long get_mod_name(const char *user_name, char **buf);
static void put_mod_name(char *buf);
@@ -368,4 +538,19 @@ err0:
}
+static spinlock_t unload_lock = SPIN_LOCK_UNLOCKED;
+int try_inc_mod_count(struct module *mod)
+{
+ int res = 1;
+ if (mod) {
+ spin_lock(_lock);
+ if (mod->flags & MOD_DELETED)
+ res = 0;
+ else
+ __MOD_INC_USE_COUNT(mod);
+ spin_unlock(_lock);
+ }
+ return res;
+}
+
asmlinkage int
sys_delete_module(const char *name_user)
@@ -1039,4 +1224,9 @@ sys_get_kernel_syms(struct kernel_sym *t
{
return -ENOSYS;
+}
+
+int try_inc_mod_count(struct module *mod)
+{
+ return 1;
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
According to Matthias Andree:
> I have a vanilla 2.2.18 that I patch Andrea Arcangeli's VM-global-7
> patch (for 2.2.18pre25) on top, as well as I²C 2.5.4, the current
> --12-09 IDE.2.2.18 patch and ReiserFS 3.5.28. So far, so good. If I now
> patch serial 5.05 on top of that, the kernel itself detects devices, but
> does nothing if it's to boot /sbin/init. ctrl-alt-del and Magic SysRq
> are both functional and can reboot the machine.
VA's current kernel includes VM-global and serial-5.05 (and lots of
other stuff :-)). The only problem we had with serial-5.05 was its
2.2/2.4 compatibility code getting confused because 2.2.18 has more
of 2.4's init macros available. Try this:
Index: tty_io.c
===
RCS file: /cvs/valinux/kernel/linux/drivers/char/tty_io.c,v
retrieving revision 1.2
retrieving revision 1.2.12.1
diff -u -2 -p -r1.2 -r1.2.12.1
--- tty_io.c2000/08/30 21:33:27 1.2
+++ tty_io.c2000/09/28 08:21:34 1.2.12.1
@@ -2185,7 +2185,4 @@ __initfunc(int tty_init(void))
espserial_init();
#endif
-#ifdef CONFIG_SERIAL
- rs_init();
-#endif
#ifdef CONFIG_COMPUTONE
ip2_init();
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
According to Matthias Andree: I have a vanilla 2.2.18 that I patch Andrea Arcangeli's VM-global-7 patch (for 2.2.18pre25) on top, as well as I²C 2.5.4, the current --12-09 IDE.2.2.18 patch and ReiserFS 3.5.28. So far, so good. If I now patch serial 5.05 on top of that, the kernel itself detects devices, but does nothing if it's to boot /sbin/init. ctrl-alt-del and Magic SysRq are both functional and can reboot the machine. VA's current kernel includes VM-global and serial-5.05 (and lots of other stuff :-)). The only problem we had with serial-5.05 was its 2.2/2.4 compatibility code getting confused because 2.2.18 has more of 2.4's init macros available. Try this: Index: tty_io.c === RCS file: /cvs/valinux/kernel/linux/drivers/char/tty_io.c,v retrieving revision 1.2 retrieving revision 1.2.12.1 diff -u -2 -p -r1.2 -r1.2.12.1 --- tty_io.c2000/08/30 21:33:27 1.2 +++ tty_io.c2000/09/28 08:21:34 1.2.12.1 @@ -2185,7 +2185,4 @@ __initfunc(int tty_init(void)) espserial_init(); #endif -#ifdef CONFIG_SERIAL - rs_init(); -#endif #ifdef CONFIG_COMPUTONE ip2_init(); -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > According to Alexander Viro: > > > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > > > According to Alexander Viro: > > > > > 9P is quite simple and unlike CORBA it had been designed for taking > > > > > kernel stuff to userland. Besides, authors definitely understand > > > > > UNIX... > > > > > > > > As nice as 9P is, it'll need some tweaks to work with Linux. > > > > For example, it limits filenames to 30 characters; that's not OK. > > > > > > For RPC-style uses? Why? > > > > For the same reason C compilers recognize more than eight significant > > characters in externals, even though ANSI doesn't require them to. > > s/30/255/ and you've got a big problem with ext2... As long as names are to be created, or at least understood, by humans, there will be some limit on *usable* length. In my experience, 255 is above that limit, but 30 is below it. And I cut my teeth on a system that had exactly that length limitation (UNOS). -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: > 9P is quite simple and unlike CORBA it had been designed for taking > kernel stuff to userland. Besides, authors definitely understand > UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: 9P is quite simple and unlike CORBA it had been designed for taking kernel stuff to userland. Besides, authors definitely understand UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: On Wed, 13 Dec 2000, Chip Salzenberg wrote: According to Alexander Viro: On Wed, 13 Dec 2000, Chip Salzenberg wrote: According to Alexander Viro: 9P is quite simple and unlike CORBA it had been designed for taking kernel stuff to userland. Besides, authors definitely understand UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. For RPC-style uses? Why? For the same reason C compilers recognize more than eight significant characters in externals, even though ANSI doesn't require them to. s/30/255/ and you've got a big problem with ext2... As long as names are to be created, or at least understood, by humans, there will be some limit on *usable* length. In my experience, 255 is above that limit, but 30 is below it. And I cut my teeth on a system that had exactly that length limitation (UNOS). -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blindingly stupid 2.2 VM bug
According to Rik van Riel:
> Luckily my patch fixes some of the suspect areas in
> VM-global [...]
Would you say that the below patch is just the try_to_free_pages
bug fix, then?
Index: mm/vmscan.c
--- mm/vmscan.c.prev
+++ mm/vmscan.c Fri Nov 24 15:17:59 2000
@@ -401,4 +401,5 @@ int try_to_free_pages(unsigned int gfp_m
int priority;
int count = SWAP_CLUSTER_MAX;
+ int loopcount = count;
int killed = 0;
@@ -409,5 +410,5 @@ int try_to_free_pages(unsigned int gfp_m
again:
- priority = 5;
+ priority = 6;
do {
while (shrink_mmap(priority, gfp_mask)) {
@@ -431,5 +432,10 @@ again:
shrink_dcache_memory(priority, gfp_mask);
- } while (--priority > 0);
+
+ /* Only lower priority if we didn't make progress. */
+ if (count == loopcount)
+ --priority;
+ loopcount = count;
+ } while (priority > 0);
done:
unlock_kernel();
@@ -454,6 +460,9 @@ done:
}
- /* Return success if we freed a page. */
- return priority > 0;
+ /* Return success if we have enough free memory or we freed a page. */
+ if (nr_free_pages > freepages.low)
+ return 1;
+
+ return count < SWAP_CLUSTER_MAX;
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blindingly stupid 2.2 VM bug
According to Rik van Riel:
Luckily my patch fixes some of the suspect areas in
VM-global [...]
Would you say that the below patch is just the try_to_free_pages
bug fix, then?
Index: mm/vmscan.c
--- mm/vmscan.c.prev
+++ mm/vmscan.c Fri Nov 24 15:17:59 2000
@@ -401,4 +401,5 @@ int try_to_free_pages(unsigned int gfp_m
int priority;
int count = SWAP_CLUSTER_MAX;
+ int loopcount = count;
int killed = 0;
@@ -409,5 +410,5 @@ int try_to_free_pages(unsigned int gfp_m
again:
- priority = 5;
+ priority = 6;
do {
while (shrink_mmap(priority, gfp_mask)) {
@@ -431,5 +432,10 @@ again:
shrink_dcache_memory(priority, gfp_mask);
- } while (--priority 0);
+
+ /* Only lower priority if we didn't make progress. */
+ if (count == loopcount)
+ --priority;
+ loopcount = count;
+ } while (priority 0);
done:
unlock_kernel();
@@ -454,6 +460,9 @@ done:
}
- /* Return success if we freed a page. */
- return priority 0;
+ /* Return success if we have enough free memory or we freed a page. */
+ if (nr_free_pages freepages.low)
+ return 1;
+
+ return count SWAP_CLUSTER_MAX;
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: NFSD dentry manipulation (was Re: d_move())
ent, then
-* it is well connected. But nobody returns different dentrys do they?
-*/
- pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
- d_drop(tdentry); /* we never want ".." hashed */
- if (!pdentry) {
- /* I don't want to return a ".." dentry.
-* I would prefer to return an unconnected "IS_ROOT" dentry,
-* though a properly connected dentry is even better
-*/
- /* if first or last of alias list is not tdentry, use that
-* else make a root dentry
-*/
- struct list_head *aliases = >d_inode->i_dentry;
- if (aliases->next != aliases) {
- pdentry = list_entry(aliases->next, struct dentry, d_alias);
- if (pdentry == tdentry)
- pdentry = list_entry(aliases->prev, struct dentry,
d_alias);
- if (pdentry == tdentry)
- pdentry = NULL;
- if (pdentry) dget(pdentry);
- }
- if (pdentry == NULL) {
- pdentry = d_alloc_root(igrab(tdentry->d_inode), NULL);
- if (pdentry) {
- pdentry->d_flags |= DCACHE_NFSD_DISCONNECTED;
- d_rehash(pdentry);
- }
- }
- if (pdentry == NULL)
- pdentry = ERR_PTR(-ENOMEM);
+ if (parent)
+ dput(dotdot); /* not hashed, thus discarded */
+ else {
+ /* Discard the ".." dentry, then arrange for a better one. */
+ struct inode *inode = igrab(dotdot->d_inode);
+ dput(dotdot); /* not hashed, thus discarded */
+ parent = nfsd_arrange_dentry(inode);
}
- dput(tdentry); /* it is not hashed, it will be discarded */
- return pdentry;
+ return parent;
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: NFSD dentry manipulation (was Re: d_move())
inode-i_op-lookup(child-d_inode, tdentry);
- d_drop(tdentry); /* we never want ".." hashed */
- if (!pdentry) {
- /* I don't want to return a ".." dentry.
-* I would prefer to return an unconnected "IS_ROOT" dentry,
-* though a properly connected dentry is even better
-*/
- /* if first or last of alias list is not tdentry, use that
-* else make a root dentry
-*/
- struct list_head *aliases = tdentry-d_inode-i_dentry;
- if (aliases-next != aliases) {
- pdentry = list_entry(aliases-next, struct dentry, d_alias);
- if (pdentry == tdentry)
- pdentry = list_entry(aliases-prev, struct dentry,
d_alias);
- if (pdentry == tdentry)
- pdentry = NULL;
- if (pdentry) dget(pdentry);
- }
- if (pdentry == NULL) {
- pdentry = d_alloc_root(igrab(tdentry-d_inode), NULL);
- if (pdentry) {
- pdentry-d_flags |= DCACHE_NFSD_DISCONNECTED;
- d_rehash(pdentry);
- }
- }
- if (pdentry == NULL)
- pdentry = ERR_PTR(-ENOMEM);
+ if (parent)
+ dput(dotdot); /* not hashed, thus discarded */
+ else {
+ /* Discard the ".." dentry, then arrange for a better one. */
+ struct inode *inode = igrab(dotdot-d_inode);
+ dput(dotdot); /* not hashed, thus discarded */
+ parent = nfsd_arrange_dentry(inode);
}
- dput(tdentry); /* it is not hashed, it will be discarded */
- return pdentry;
+ return parent;
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries (Dentry Corruption!)
This may be 2.2.18 material after all I wrote last night:
> Making nfsd's d_splice() compensate for d_move's limitations is not
> only a kludge, but also it harder to keep nfsd correct.
> someday, nfsd may not be the only creator of this kind of dentry.
Sure enough, there is just such a bug *already* in nfsd. Nfsd's
cleanup after d_move is incomplete: It handles one of the dentries
being parentless, but not the other one. This bug *will* cause dentry
corruption.[1] It may well be what's been causing the hangs that my
recent patches seem to have fixed.
Therefore, in the mainline kernel, we need either the below patch to
d_move (along with a trivial simplifcation of nfsd's use of it), or an
expansion of the kludge in nfsd. You can guess which one I favor
[1] The bug can only show up when reconstructing pruned dentries, and
only under a specific pattern of client requests, so it's not
surprising that it is rarely observed in the wild.
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(>d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry->d_name.len, target->d_name.len);
+ do_switch(dentry->d_name.hash, target->d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(>d_child);
list_del(>d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry->d_parent, target->d_parent);
- do_switch(dentry->d_name.len, target->d_name.len);
- do_switch(dentry->d_name.hash, target->d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(>d_child, >d_parent->d_subdirs);
- list_add(>d_child, >d_parent->d_subdirs);
+ if (dentry->d_parent != target)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ dentry->d_parent = dentry;
+ }
+ if (target->d_parent != dentry)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ target->d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries
The d_move() function doesn't correctly handle dentries that have no
parents (i.e. 'x->d_parent==x'). This patch lets it do so.
Normally, the only parentless dentries are filesystem roots. However,
the NFS server creates (temporary) parentless dentries whenever dentry
pruning has deleted the dentries referring to clients' open files.
Making nfsd's d_splice() compensate for d_move's limitations is not
only a kludge, but also it harder to keep nfsd correct. Besides,
someday, nfsd may not be the only creator of this kind of dentry.
Thus, this patch. If you apply this, you'll also want to patch
fs/nfsd/nfsfh.c to stop compensating for d_move's old limitations.
(Alan, this is 2.2.19 material [if then].)
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(>d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry->d_name.len, target->d_name.len);
+ do_switch(dentry->d_name.hash, target->d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(>d_child);
list_del(>d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry->d_parent, target->d_parent);
- do_switch(dentry->d_name.len, target->d_name.len);
- do_switch(dentry->d_name.hash, target->d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(>d_child, >d_parent->d_subdirs);
- list_add(>d_child, >d_parent->d_subdirs);
+ if (dentry->d_parent != target)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ dentry->d_parent = dentry;
+ }
+ if (target->d_parent != dentry)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ target->d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries
The d_move() function doesn't correctly handle dentries that have no
parents (i.e. 'x-d_parent==x'). This patch lets it do so.
Normally, the only parentless dentries are filesystem roots. However,
the NFS server creates (temporary) parentless dentries whenever dentry
pruning has deleted the dentries referring to clients' open files.
Making nfsd's d_splice() compensate for d_move's limitations is not
only a kludge, but also it harder to keep nfsd correct. Besides,
someday, nfsd may not be the only creator of this kind of dentry.
Thus, this patch. If you apply this, you'll also want to patch
fs/nfsd/nfsfh.c to stop compensating for d_move's old limitations.
(Alan, this is 2.2.19 material [if then].)
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(target-d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry-d_name.len, target-d_name.len);
+ do_switch(dentry-d_name.hash, target-d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(dentry-d_child);
list_del(target-d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry-d_parent, target-d_parent);
- do_switch(dentry-d_name.len, target-d_name.len);
- do_switch(dentry-d_name.hash, target-d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(target-d_child, target-d_parent-d_subdirs);
- list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ if (dentry-d_parent != target)
+ list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(dentry-d_child);
+ dentry-d_parent = dentry;
+ }
+ if (target-d_parent != dentry)
+ list_add(target-d_child, target-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(target-d_child);
+ target-d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries (Dentry Corruption!)
This may be 2.2.18 material after all I wrote last night:
Making nfsd's d_splice() compensate for d_move's limitations is not
only a kludge, but also it harder to keep nfsd correct.
someday, nfsd may not be the only creator of this kind of dentry.
Sure enough, there is just such a bug *already* in nfsd. Nfsd's
cleanup after d_move is incomplete: It handles one of the dentries
being parentless, but not the other one. This bug *will* cause dentry
corruption.[1] It may well be what's been causing the hangs that my
recent patches seem to have fixed.
Therefore, in the mainline kernel, we need either the below patch to
d_move (along with a trivial simplifcation of nfsd's use of it), or an
expansion of the kludge in nfsd. You can guess which one I favor
[1] The bug can only show up when reconstructing pruned dentries, and
only under a specific pattern of client requests, so it's not
surprising that it is rarely observed in the wild.
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(target-d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry-d_name.len, target-d_name.len);
+ do_switch(dentry-d_name.hash, target-d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(dentry-d_child);
list_del(target-d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry-d_parent, target-d_parent);
- do_switch(dentry-d_name.len, target-d_name.len);
- do_switch(dentry-d_name.hash, target-d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(target-d_child, target-d_parent-d_subdirs);
- list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ if (dentry-d_parent != target)
+ list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(dentry-d_child);
+ dentry-d_parent = dentry;
+ }
+ if (target-d_parent != dentry)
+ list_add(target-d_child, target-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(target-d_child);
+ target-d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre21: DRM update
This is an update from the main DRM tree, but with cosmetic changes
removed and only meat left. This patch is already in VA's shipping
kernel, so you know we really trust it. :-,
BTW, this patch is not fluff: It includes bug fixes. But it's pretty
big, so if you want to wait until 2.2.19 I'll understand
Index: drivers/char/Makefile
--- drivers/char/Makefile.prev
+++ drivers/char/Makefile Fri Nov 17 13:30:04 2000
@@ -12,5 +12,5 @@
SUB_DIRS :=
MOD_SUB_DIRS := $(SUB_DIRS)
-ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick drm agp
+ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick
#
@@ -395,4 +395,16 @@
endif
+ifeq ($(CONFIG_DRM),y)
+O_OBJS += drm/drm.o
+ALL_SUB_DIRS += drm
+MOD_SUB_DIRS += drm
+SUB_DIRS += drm
+else
+ ifeq ($(CONFIG_DRM),m)
+ ALL_SUB_DIRS += drm
+ MOD_SUB_DIRS += drm
+ endif
+endif
+
ifeq ($(CONFIG_INTEL_RNG),y)
O_OBJS += i810_rng.o
@@ -650,16 +662,4 @@
OX_OBJS += h8.o
endif
-
-
-ifeq ($(CONFIG_DRM),y)
-SUB_DIRS += drm
-O_OBJS += drm/drm.o
-MOD_SUB_DIRS += drm
-else
- ifeq ($(CONFIG_DRM),m)
- MOD_SUB_DIRS += drm
- endif
-endif
-
ifeq ($(L_I2C),y)
Index: drivers/char/drm/drmP.h
--- drivers/char/drm/drmP.h.prev
+++ drivers/char/drm/drmP.h Fri Nov 17 13:30:04 2000
@@ -34,4 +34,9 @@
#ifdef __KERNEL__
+#ifdef __alpha__
+/* add include of current.h so that "current" is defined
+ * before static inline funcs in wait.h. 4/21/2000 S + B */
+#include
+#endif /* __alpha__ */
#include
#include
@@ -47,8 +52,11 @@
#include
#include /* For (un)lock_kernel */
+#include
+#ifdef __alpha__
+#include /* For pte_wrprotect */
+#endif
#include
#include
#include
-#include
#ifdef CONFIG_MTRR
#include
@@ -133,8 +141,86 @@
#endif
+ /* module_init/module_exit added in 2.3.13 */
+#ifndef module_init
+#define module_init(x) int init_module(void) { return x(); }
+#endif
+#ifndef module_exit
+#define module_exit(x) void cleanup_module(void) { x(); }
+#endif
+
+ /* virt_to_page added in 2.4.0-test6 */
+#if LINUX_VERSION_CODE < 0x020400
+#define virt_to_page(kaddr) (mem_map + MAP_NR(kaddr))
+#endif
+
/* Generic cmpxchg added in 2.3.x */
#ifndef __HAVE_ARCH_CMPXCHG
/* Include this here so that driver can be
used with older kernels. */
+#if defined(__alpha__)
+static __inline__ unsigned long
+__cmpxchg_u32(volatile int *m, int old, int new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldl_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stl_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "="(prev), "="(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldq_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stq_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "="(prev), "="(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+ switch (size) {
+ case 4:
+ return __cmpxchg_u32(ptr, old, new);
+ case 8:
+ return __cmpxchg_u64(ptr, old, new);
+ }
+ return old;
+}
+#define cmpxchg(ptr,o,n)\
+ ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr))); \
+ })
+
+#elif __i386__
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
@@ -167,4 +253,5 @@
((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o), \
(unsigned long)(n),sizeof(*(ptr
+#endif /* i386 & alpha */
#endif
@@ -316,4 +403,5 @@
int high_mark; /* High water mark */
atomic_t wfh; /* If waiting for high mark */
+ spinlock_tlock;
} drm_freelist_t;
@@ -344,4 +432,5 @@
struct drm_file *prev;
struct drm_device *dev;
+
[PATCH] 2.2.18pre21: DRM update
This is an update from the main DRM tree, but with cosmetic changes
removed and only meat left. This patch is already in VA's shipping
kernel, so you know we really trust it. :-,
BTW, this patch is not fluff: It includes bug fixes. But it's pretty
big, so if you want to wait until 2.2.19 I'll understand
Index: drivers/char/Makefile
--- drivers/char/Makefile.prev
+++ drivers/char/Makefile Fri Nov 17 13:30:04 2000
@@ -12,5 +12,5 @@
SUB_DIRS :=
MOD_SUB_DIRS := $(SUB_DIRS)
-ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick drm agp
+ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick
#
@@ -395,4 +395,16 @@
endif
+ifeq ($(CONFIG_DRM),y)
+O_OBJS += drm/drm.o
+ALL_SUB_DIRS += drm
+MOD_SUB_DIRS += drm
+SUB_DIRS += drm
+else
+ ifeq ($(CONFIG_DRM),m)
+ ALL_SUB_DIRS += drm
+ MOD_SUB_DIRS += drm
+ endif
+endif
+
ifeq ($(CONFIG_INTEL_RNG),y)
O_OBJS += i810_rng.o
@@ -650,16 +662,4 @@
OX_OBJS += h8.o
endif
-
-
-ifeq ($(CONFIG_DRM),y)
-SUB_DIRS += drm
-O_OBJS += drm/drm.o
-MOD_SUB_DIRS += drm
-else
- ifeq ($(CONFIG_DRM),m)
- MOD_SUB_DIRS += drm
- endif
-endif
-
ifeq ($(L_I2C),y)
Index: drivers/char/drm/drmP.h
--- drivers/char/drm/drmP.h.prev
+++ drivers/char/drm/drmP.h Fri Nov 17 13:30:04 2000
@@ -34,4 +34,9 @@
#ifdef __KERNEL__
+#ifdef __alpha__
+/* add include of current.h so that "current" is defined
+ * before static inline funcs in wait.h. 4/21/2000 S + B */
+#include asm/current.h
+#endif /* __alpha__ */
#include linux/config.h
#include linux/module.h
@@ -47,8 +52,11 @@
#include linux/sched.h
#include linux/smp_lock.h/* For (un)lock_kernel */
+#include linux/mm.h
+#ifdef __alpha__
+#include asm/pgtable.h /* For pte_wrprotect */
+#endif
#include asm/io.h
#include asm/mman.h
#include asm/uaccess.h
-#include asm/pgtable.h
#ifdef CONFIG_MTRR
#include asm/mtrr.h
@@ -133,8 +141,86 @@
#endif
+ /* module_init/module_exit added in 2.3.13 */
+#ifndef module_init
+#define module_init(x) int init_module(void) { return x(); }
+#endif
+#ifndef module_exit
+#define module_exit(x) void cleanup_module(void) { x(); }
+#endif
+
+ /* virt_to_page added in 2.4.0-test6 */
+#if LINUX_VERSION_CODE 0x020400
+#define virt_to_page(kaddr) (mem_map + MAP_NR(kaddr))
+#endif
+
/* Generic cmpxchg added in 2.3.x */
#ifndef __HAVE_ARCH_CMPXCHG
/* Include this here so that driver can be
used with older kernels. */
+#if defined(__alpha__)
+static __inline__ unsigned long
+__cmpxchg_u32(volatile int *m, int old, int new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldl_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stl_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "=r"(prev), "=r"(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldq_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stq_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "=r"(prev), "=r"(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+ switch (size) {
+ case 4:
+ return __cmpxchg_u32(ptr, old, new);
+ case 8:
+ return __cmpxchg_u64(ptr, old, new);
+ }
+ return old;
+}
+#define cmpxchg(ptr,o,n)\
+ ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr))); \
+ })
+
+#elif __i386__
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
@@ -167,4 +253,5 @@
((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o), \
(unsigned long)(n),sizeof(*(ptr
+#endif /* i386 alpha */
#endif
@@ -316,4 +403,5 @@
int high_mark; /* High water mark */
atomic_t wfh; /* If waiting for high mark
Re: 2.2.18pre13: Small patches
According to Jeff Garzik: > The correct fix is a much larger patch which changes char2uni's > declaration to include const, and then all the changes that trickle down > from there. I didn't want to presume to change an API like that, even an internal one. But of course Alan can, and I'm quite glad he did. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre13: Small patches
According to Jeff Garzik: The correct fix is a much larger patch which changes char2uni's declaration to include const, and then all the changes that trickle down from there. I didn't want to presume to change an API like that, even an internal one. But of course Alan can, and I'm quite glad he did. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: eepro100 debug, take 2
This time, it checks for CAP_NET_ADMIN before adjusting the debug
level. (Duh)
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c2000/09/06 19:54:42 1.4
+++ linux/drivers/net/eepro100.c2000/10/02 22:44:12 1.4.8.2
@@ -1,4 +1,2 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
@@ -40,4 +38,9 @@
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
@@ -1148,6 +1151,4 @@ static void speedo_show_state(struct net
{
struct speedo_private *sp = (struct speedo_private *)dev->priv;
- long ioaddr = dev->base_addr;
- int phy_num = sp->phy[0] & 0x1f;
int i;
@@ -1176,4 +1177,8 @@ static void speedo_show_state(struct net
#if 0
+ {
+ long ioaddr = dev->base_addr;
+ int phy_num = sp->phy[0] & 0x1f;
+
for (i = 0; i < 16; i++) {
/* FIXME: what does it mean? --SAW */
@@ -1182,4 +1187,5 @@ static void speedo_show_state(struct net
dev->name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
@@ -1509,5 +1515,5 @@ static void speedo_interrupt(int irq, vo
outw(status & 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug > 4)
+ if (speedo_debug > 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev->name, status);
@@ -1932,4 +1938,11 @@ static int speedo_ioctl(struct net_devic
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5: /* Set speedo debug level */
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ speedo_debug = *(int *)rq->ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev->name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
@@ -1971,4 +1984,8 @@ static void set_rx_mode(struct net_devic
* set again later. */
sp->rx_mode = -1;
+ if(speedo_debug < 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp->cur_tx[%d], sp->dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev->name, sp->cur_tx, sp->dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18pre13: eepro100 debug tweaks
According to Alan Cox: > > + case SIOCDEVPRIVATE+5: > > + speedo_debug = *(int *)rq->ifr_data; > > + printk(KERN_DEBUG "%s: set debug level to [%d].\n", > > + dev->name, speedo_debug); > > + return 0; > > Surely that should check for root ? Now see, this is why peer review is a Good Thing. :-/ Yes, of course it should check for root. (I'm dunce-for-a-day for not seeing that immediately.) -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec >= 100) {
- sec += 1;
- usec -= 100;
- }
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(_lock, flags);
- while (usec >= 100) {
- usec -= 100;
- sec++;
- }
-
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv->tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv->tv_usec >= 100) {
- tv->tv_usec -= 100;
- tv->tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/li
[PATCH] 2.2.18pre13: eepro100 debug tweaks
Patch: eepro100-speedo-debug-1
From: Dragan Stancevic <[EMAIL PROTECTED]>
Debugging tweaks for eepro100 driver:
* Add ioctl to adjust speedo_debug.
* Print diagnostic when Tx ring fills up.
* Adjust debugging level of interrupt diagnostics.
* Eliminate compilation warning.
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c:1.4Wed Sep 6 12:54:42 2000
+++ linux/drivers/net/eepro100.cThu Sep 28 01:07:37 2000
@@ -1,5 +1,3 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
NOTICE: this version of the driver is supposed to work with 2.2 kernels.
@@ -39,6 +37,11 @@
Honor PortReset timing specification.
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
"eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
<[EMAIL PROTECTED]> and others\n";
@@ -1147,8 +1150,6 @@
static void speedo_show_state(struct net_device *dev)
{
struct speedo_private *sp = (struct speedo_private *)dev->priv;
- long ioaddr = dev->base_addr;
- int phy_num = sp->phy[0] & 0x1f;
int i;
/* Print a few items for debugging. */
@@ -1175,12 +1176,17 @@
(unsigned)sp->rx_ringp[i]->status : 0);
#if 0
+ {
+ long ioaddr = dev->base_addr;
+ int phy_num = sp->phy[0] & 0x1f;
+
for (i = 0; i < 16; i++) {
/* FIXME: what does it mean? --SAW */
if (i == 6) i = 21;
printk(KERN_DEBUG "%s: PHY index %d register %d is %4.4x.\n",
dev->name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
}
@@ -1508,7 +1514,7 @@
FCP and ER interrupts --Dragan */
outw(status & 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug > 4)
+ if (speedo_debug > 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev->name, status);
@@ -1931,6 +1937,11 @@
mdio_write(ioaddr, data[0], data[1], data[2]);
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5:
+ speedo_debug = *(int *)rq->ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev->name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
}
@@ -1970,6 +1981,10 @@
/* The Tx ring is full -- don't add anything! Hope the mode will be
* set again later. */
sp->rx_mode = -1;
+ if(speedo_debug < 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp->cur_tx[%d], sp->dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev->name, sp->cur_tx, sp->dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre13: Small patches
Here's a brace of small patches that ought to be OK for 2.2.18.
adTHANKSvance for consideration
1. Fix fencepost error in ioremap's page reservation logic.
(I think the broken logic was added to support AGP.)
Index: linux/arch/i386/mm/ioremap.c
--- linux/arch/i386/mm/ioremap.c:1.2Fri Sep 1 19:03:09 2000
+++ linux/arch/i386/mm/ioremap.cThu Sep 28 00:34:40 2000
@@ -117,7 +117,7 @@
temp_addr = __va(phys_addr);
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i < MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i <= MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
}
2. Fix linear RAID to work even with blocks smaller than 1K.
(From Anton Altparmakov <[EMAIL PROTECTED]>)
In linux/drivers/block/linear.c:linear_map(), change:
*rsector=(block-(tmp_dev->offset)) << 1;
to:
*rsector=((block - tmp_dev->offset) << 1) + (*rsector & 1);
3. Trivial patch to fs/vfat/namei.c to avoid a compile-time warning.
Index: linux/fs/vfat/namei.c
--- linux/fs/vfat/namei.c:1.2 Fri Sep 1 19:03:16 2000
+++ linux/fs/vfat/namei.c Thu Sep 28 00:53:55 2000
@@ -676,7 +676,8 @@
i += 4;
} else {
int llen;
- nls->char2uni(ip, , op, op+1);
+ nls->char2uni((unsigned char *)ip,
+ , op, op+1);
op += 2;
ip += llen;
i += llen;
4. Config option controlling default behavior of kernels that enable
boot-time IP-Config.
* If CONFIG_IP_PNP_AUTO is set, the default is to do IP-Config at
boot time. Disable it with "ip=off".
* If CONFIG_IP_PNP_AUTO is not set, the default is *not* to do
IP-Config at boot time. Override with "ip=on", "ip=dhcp", etc.
Index: linux/net/ipv4/Config.in
diff -u linux/net/ipv4/Config.in:1.2 linux/net/ipv4/Config.in:1.2.8.1
--- linux/net/ipv4/Config.in:1.2Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/Config.inThu Sep 28 00:42:00 2000
@@ -22,6 +22,9 @@
bool ' RARP support' CONFIG_IP_PNP_RARP
# not yet ready..
# bool ' ARP support' CONFIG_IP_PNP_ARP
+ if [ "$CONFIG_IP_PNP_DHCP" = "y" -o "$CONFIG_IP_PNP_BOOTP" = "y" -o
+"$CONFIG_IP_PNP_RARP" = "y" ]; then
+bool ' Auto DHCP/BOOTP/RARP at boot' CONFIG_IP_PNP_AUTO
+ fi
fi
if [ "$CONFIG_FIREWALL" = "y" ]; then
bool 'IP: firewalling' CONFIG_IP_FIREWALL
Index: linux/net/ipv4/ipconfig.c
diff -u linux/net/ipv4/ipconfig.c:1.2 linux/net/ipv4/ipconfig.c:1.2.8.1
--- linux/net/ipv4/ipconfig.c:1.2 Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/ipconfig.c Thu Sep 28 00:42:00 2000
@@ -87,7 +87,13 @@
* Public IP configuration
*/
-int ic_enable __initdata = 0; /* IP config enabled? */
+int ic_enable __initdata = /* IP config enabled? */
+#ifdef CONFIG_IP_PNP_AUTO
+ 1
+#else
+ 0
+#endif
+;
/* Protocol choice */
static int ic_proto_enabled __initdata = 0
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: USB tweak for VAIO
Patch: usbdock-1
From: Geoff Harrison <[EMAIL PROTECTED]>
Allow short report frames via USB ... apparently they are normal for
some Sony VAIOs when docked.
Index: linux/drivers/usb/hid.c
diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
--- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
+++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
@@ -1096,10 +1096,12 @@
return;
}
+#if 0
if (len < ((report->size - 1) >> 3) + 1) {
dbg("report %d is too short, (%d < %d)", report->id, len,
((report->size - 1) >> 3) + 1);
return;
}
+#endif
for (n = 0; n < report->maxfield; n++)
hid_input_field(device, report->field[n], data);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre13: Small patches
Here's a brace of small patches that ought to be OK for 2.2.18.
adTHANKSvance for consideration
1. Fix fencepost error in ioremap's page reservation logic.
(I think the broken logic was added to support AGP.)
Index: linux/arch/i386/mm/ioremap.c
--- linux/arch/i386/mm/ioremap.c:1.2Fri Sep 1 19:03:09 2000
+++ linux/arch/i386/mm/ioremap.cThu Sep 28 00:34:40 2000
@@ -117,7 +117,7 @@
temp_addr = __va(phys_addr);
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i = MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
}
2. Fix linear RAID to work even with blocks smaller than 1K.
(From Anton Altparmakov [EMAIL PROTECTED])
In linux/drivers/block/linear.c:linear_map(), change:
*rsector=(block-(tmp_dev-offset)) 1;
to:
*rsector=((block - tmp_dev-offset) 1) + (*rsector 1);
3. Trivial patch to fs/vfat/namei.c to avoid a compile-time warning.
Index: linux/fs/vfat/namei.c
--- linux/fs/vfat/namei.c:1.2 Fri Sep 1 19:03:16 2000
+++ linux/fs/vfat/namei.c Thu Sep 28 00:53:55 2000
@@ -676,7 +676,8 @@
i += 4;
} else {
int llen;
- nls-char2uni(ip, llen, op, op+1);
+ nls-char2uni((unsigned char *)ip,
+ llen, op, op+1);
op += 2;
ip += llen;
i += llen;
4. Config option controlling default behavior of kernels that enable
boot-time IP-Config.
* If CONFIG_IP_PNP_AUTO is set, the default is to do IP-Config at
boot time. Disable it with "ip=off".
* If CONFIG_IP_PNP_AUTO is not set, the default is *not* to do
IP-Config at boot time. Override with "ip=on", "ip=dhcp", etc.
Index: linux/net/ipv4/Config.in
diff -u linux/net/ipv4/Config.in:1.2 linux/net/ipv4/Config.in:1.2.8.1
--- linux/net/ipv4/Config.in:1.2Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/Config.inThu Sep 28 00:42:00 2000
@@ -22,6 +22,9 @@
bool ' RARP support' CONFIG_IP_PNP_RARP
# not yet ready..
# bool ' ARP support' CONFIG_IP_PNP_ARP
+ if [ "$CONFIG_IP_PNP_DHCP" = "y" -o "$CONFIG_IP_PNP_BOOTP" = "y" -o
+"$CONFIG_IP_PNP_RARP" = "y" ]; then
+bool ' Auto DHCP/BOOTP/RARP at boot' CONFIG_IP_PNP_AUTO
+ fi
fi
if [ "$CONFIG_FIREWALL" = "y" ]; then
bool 'IP: firewalling' CONFIG_IP_FIREWALL
Index: linux/net/ipv4/ipconfig.c
diff -u linux/net/ipv4/ipconfig.c:1.2 linux/net/ipv4/ipconfig.c:1.2.8.1
--- linux/net/ipv4/ipconfig.c:1.2 Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/ipconfig.c Thu Sep 28 00:42:00 2000
@@ -87,7 +87,13 @@
* Public IP configuration
*/
-int ic_enable __initdata = 0; /* IP config enabled? */
+int ic_enable __initdata = /* IP config enabled? */
+#ifdef CONFIG_IP_PNP_AUTO
+ 1
+#else
+ 0
+#endif
+;
/* Protocol choice */
static int ic_proto_enabled __initdata = 0
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: USB tweak for VAIO
Patch: usbdock-1
From: Geoff Harrison [EMAIL PROTECTED]
Allow short report frames via USB ... apparently they are normal for
some Sony VAIOs when docked.
Index: linux/drivers/usb/hid.c
diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
--- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
+++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
@@ -1096,10 +1096,12 @@
return;
}
+#if 0
if (len ((report-size - 1) 3) + 1) {
dbg("report %d is too short, (%d %d)", report-id, len,
((report-size - 1) 3) + 1);
return;
}
+#endif
for (n = 0; n report-maxfield; n++)
hid_input_field(device, report-field[n], data);
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: eepro100 debug tweaks
Patch: eepro100-speedo-debug-1
From: Dragan Stancevic [EMAIL PROTECTED]
Debugging tweaks for eepro100 driver:
* Add ioctl to adjust speedo_debug.
* Print diagnostic when Tx ring fills up.
* Adjust debugging level of interrupt diagnostics.
* Eliminate compilation warning.
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c:1.4Wed Sep 6 12:54:42 2000
+++ linux/drivers/net/eepro100.cThu Sep 28 01:07:37 2000
@@ -1,5 +1,3 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
NOTICE: this version of the driver is supposed to work with 2.2 kernels.
@@ -39,6 +37,11 @@
Honor PortReset timing specification.
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
"eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
[EMAIL PROTECTED] and others\n";
@@ -1147,8 +1150,6 @@
static void speedo_show_state(struct net_device *dev)
{
struct speedo_private *sp = (struct speedo_private *)dev-priv;
- long ioaddr = dev-base_addr;
- int phy_num = sp-phy[0] 0x1f;
int i;
/* Print a few items for debugging. */
@@ -1175,12 +1176,17 @@
(unsigned)sp-rx_ringp[i]-status : 0);
#if 0
+ {
+ long ioaddr = dev-base_addr;
+ int phy_num = sp-phy[0] 0x1f;
+
for (i = 0; i 16; i++) {
/* FIXME: what does it mean? --SAW */
if (i == 6) i = 21;
printk(KERN_DEBUG "%s: PHY index %d register %d is %4.4x.\n",
dev-name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
}
@@ -1508,7 +1514,7 @@
FCP and ER interrupts --Dragan */
outw(status 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug 4)
+ if (speedo_debug 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev-name, status);
@@ -1931,6 +1937,11 @@
mdio_write(ioaddr, data[0], data[1], data[2]);
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5:
+ speedo_debug = *(int *)rq-ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev-name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
}
@@ -1970,6 +1981,10 @@
/* The Tx ring is full -- don't add anything! Hope the mode will be
* set again later. */
sp-rx_mode = -1;
+ if(speedo_debug 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp-cur_tx[%d], sp-dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev-name, sp-cur_tx, sp-dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli [EMAIL PROTECTED]
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec = 100) {
- sec += 1;
- usec -= 100;
- }
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(xtime_lock, flags);
- while (usec = 100) {
- usec -= 100;
- sec++;
- }
-
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv-tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv-tv_usec = 100) {
- tv-tv_usec -= 100;
- tv-tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/linux/time.h:1.1.14.1
--- linux/include/linux/time.h:1.1 Thu Jul 6 22:04:59 2000
+++ l
Re: [PATCH] 2.2.18pre13: eepro100 debug tweaks
According to Alan Cox: + case SIOCDEVPRIVATE+5: + speedo_debug = *(int *)rq-ifr_data; + printk(KERN_DEBUG "%s: set debug level to [%d].\n", + dev-name, speedo_debug); + return 0; Surely that should check for root ? Now see, this is why peer review is a Good Thing. :-/ Yes, of course it should check for root. (I'm dunce-for-a-day for not seeing that immediately.) -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: eepro100 debug, take 2
This time, it checks for CAP_NET_ADMIN before adjusting the debug
level. (Duh)
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c2000/09/06 19:54:42 1.4
+++ linux/drivers/net/eepro100.c2000/10/02 22:44:12 1.4.8.2
@@ -1,4 +1,2 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
@@ -40,4 +38,9 @@
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
@@ -1148,6 +1151,4 @@ static void speedo_show_state(struct net
{
struct speedo_private *sp = (struct speedo_private *)dev-priv;
- long ioaddr = dev-base_addr;
- int phy_num = sp-phy[0] 0x1f;
int i;
@@ -1176,4 +1177,8 @@ static void speedo_show_state(struct net
#if 0
+ {
+ long ioaddr = dev-base_addr;
+ int phy_num = sp-phy[0] 0x1f;
+
for (i = 0; i 16; i++) {
/* FIXME: what does it mean? --SAW */
@@ -1182,4 +1187,5 @@ static void speedo_show_state(struct net
dev-name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
@@ -1509,5 +1515,5 @@ static void speedo_interrupt(int irq, vo
outw(status 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug 4)
+ if (speedo_debug 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev-name, status);
@@ -1932,4 +1938,11 @@ static int speedo_ioctl(struct net_devic
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5: /* Set speedo debug level */
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ speedo_debug = *(int *)rq-ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev-name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
@@ -1971,4 +1984,8 @@ static void set_rx_mode(struct net_devic
* set again later. */
sp-rx_mode = -1;
+ if(speedo_debug 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp-cur_tx[%d], sp-dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev-name, sp-cur_tx, sp-dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
According to Alan Cox: > Remind me next time I get to deal with crap from VA customers because VA > shipped unusable NFS patches and broken PIII FXSAVE code that I'd vetoed > from RH kernels [...] NFS and FXSAVE. Ouch. Well, let's set the stage for the future: I'm doing kernel coordination for VA now. And I'm very careful not to break things. I may make mistakes -- heck, I *will* make mistakes; it's a big kernel, after all -- but I won't be negligent. I care greatly about stability ... just ask anyone who was around for the upgrade from Perl 5.3 to 5.4. BTW, VA's current kernel-in-testing has Trond's (now your! :-)) NFS, rock-solid NFSD from Neil Brown and Dave Higgen, and FXSAVE support back-ported from 2.4. I hope to get much of VA's kernel-in-testing patch set into mainline 2.2 ... keeping up with N/2 patches is 4x easier than N. (Or at least it seems so.) -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
According to Alan Cox: Remind me next time I get to deal with crap from VA customers because VA shipped unusable NFS patches and broken PIII FXSAVE code that I'd vetoed from RH kernels [...] NFS and FXSAVE. Ouch. Well, let's set the stage for the future: I'm doing kernel coordination for VA now. And I'm very careful not to break things. I may make mistakes -- heck, I *will* make mistakes; it's a big kernel, after all -- but I won't be negligent. I care greatly about stability ... just ask anyone who was around for the upgrade from Perl 5.3 to 5.4. BTW, VA's current kernel-in-testing has Trond's (now your! :-)) NFS, rock-solid NFSD from Neil Brown and Dave Higgen, and FXSAVE support back-ported from 2.4. I hope to get much of VA's kernel-in-testing patch set into mainline 2.2 ... keeping up with N/2 patches is 4x easier than N. (Or at least it seems so.) -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Distro kernel patches (was Re: Linux 2.2.18pre4)
According to Ralf Gerbig: > but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. You've just made L-K's understatement of the day. VA has always shipped a patched kernel. As of a few weeks ago, I'm VA's new kernel coordinator. We're not quite done with the current internal development cycle for a new kernel; but already we've applied to our kernel tree about a dozen major patches and over fifty minor ones. And that's on top of 2.2.18pre, into which Alan had already merged USB, AGP, and DRM (Thanks, Alan!!!). People who run big systems and big applications need these patches: 2.4 isn't ready for production use, stock 2.2 can't make full use of modern hardware, and the world is moving at Internet time. And VA's patching habits are the rule, not the exception. Andrea makes SuSE's kernel, and anyone who's scanned people/andrea on kernel.org knows how many patches he uses. (I greatly appreciate Andrea's patch archive, BTW. It's a great place to get major patches reconciled with each other.) And Red Hat's kernel, last I looked, had over 150 patches on top of 2.2.14. On the other hand, just because patching is inevitable doesn't mean that reducing it isn't worthwhile. The more de facto standard patches (*cough* NFS RAID[1] HedrickIDE *ahem*) can get into the 2.2 tree, the easier it will be for everyone to stay up to date, and the less effort will be wasted on basically clerical patch maintenance work. [1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] [2] Having complained about a problem, have I just volunteered myself to solve it? (HHOS) -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
According to Mike Castle: > On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: > > So basically the situation is that people prefer to switch the whole > > OS as opposed to applying a kernel patch? > > Or multiple kernel patches. > NFS. RAID. IDE. Bigmem. LVM. LFS. Rawio. Serial. Ext3. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
According to Mike Castle: On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Or multiple kernel patches. NFS. RAID. IDE. Bigmem. LVM. LFS. Rawio. Serial. Ext3. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2: gcc 2.7 doesn't like __attr__((unused))
According to Alan Cox: > > I'm not sure if __attribute__((unused)) has an equivalent in gcc 2.7, > > but as it appears in the AGP driver, it doesn't work with gcc 2.7. > > Try static void __attribute((unused)) unused(void) I'm afraid that didn't work either. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2: gcc 2.7 doesn't like __attr__((unused))
According to Alan Cox: I'm not sure if __attribute__((unused)) has an equivalent in gcc 2.7, but as it appears in the AGP driver, it doesn't work with gcc 2.7. Try static void __attribute((unused)) unused(void) I'm afraid that didn't work either. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre2: fencepost error in __ioremap() [AGP]
The AGP patches add some code to __ioremap. That code seems to me to
have a fencepost error.
In the below hunk, note that temp_end is set to "temp_addr+(size-1)".
It points _at_ the last page to be examined, not beyond it. So the
loop should be controlled by a "<=" test, not a "<" test. Without
this patch, the last page in the range is not tested for reservation.
Index: arch/i386/mm/ioremap.c
--- arch/i386/mm/ioremap.c.prev
+++ arch/i386/mm/ioremap.c Fri Sep 1 20:11:25 2000
@@ -118,5 +118,5 @@ void * __ioremap(unsigned long phys_addr
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i < MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i <= MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre2: AGP and the i810
First, thanks, Alan, for using the USB and AGP patches. You just
saved me a bunch of integration work.
I'd like to suggest the below patches for the AGP i810 driver.
[1] I'm largely in the dark with AGP, but I know for a fact that with
my previous AGP driver -- which was, like the one you integrated,
based on 2.4 and PI's work -- I got kernel oopses about 10% of the
time when exiting X. The oopses were fixed by the addition of
CACHE_FLUSH() calls in intel_i810_remove_entries(), in imitation of
the CACHE_FLUSH() calls already in intel_i810_insert_entries().
Index: drivers/char/agp/agpgart_be.c
--- drivers/char/agp/agpgart_be.c.prev
+++ drivers/char/agp/agpgart_be.c Fri Sep 1 20:38:18 2000
@@ -951,4 +953,5 @@ static int intel_i810_remove_entries(agp
int i;
+ CACHE_FLUSH();
for (i = pg_start; i < (mem->page_count + pg_start); i++) {
OUTREG32(intel_i810_private.registers,
@@ -956,4 +959,5 @@ static int intel_i810_remove_entries(agp
agp_bridge.scratch_page);
}
+ CACHE_FLUSH();
agp_bridge.tlb_flush(mem);
[2] When CONFIG_AGP_I810 is off, disable compilation of (more of the)
i810-specific code.
Index: drivers/char/agp/agpgart_be.c
--- drivers/char/agp/agpgart_be.c.prev
+++ drivers/char/agp/agpgart_be.c Fri Sep 1 20:38:18 2000
@@ -791,4 +791,6 @@ void agp_enable(u32 mode)
/* End - Generic Agp routines */
+#ifdef CONFIG_AGP_I810
+
static aper_size_info_fixed intel_i810_sizes[] =
{
@@ -1063,4 +1067,5 @@ static int __init intel_i810_setup(struc
}
+#endif /* CONFIG_AGP_I810 */
#ifdef CONFIG_AGP_INTEL
@@ -2198,5 +2203,5 @@ static int __init agp_find_supported_dev
/* Need to test for I810 here */
-
+#ifdef CONFIG_AGP_I810
if (dev->vendor == PCI_VENDOR_ID_INTEL) {
struct pci_dev *i810_dev;
@@ -2272,5 +2277,5 @@ static int __init agp_find_supported_dev
}
}
-
+#endif /* CONFIG_AGP_I810 */
/* find capndx */
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre2: gcc 2.7 doesn't like __attr__((unused))
I'm not sure if __attribute__((unused)) has an equivalent in gcc 2.7,
but as it appears in the AGP driver, it doesn't work with gcc 2.7.
Below is the patch I used to get AGP to compile, but I don't recommend
it for adoption in the standard source tree.
Index: drivers/char/drm/ffb_drv.c
--- drivers/char/drm/ffb_drv.c.prev
+++ drivers/char/drm/ffb_drv.c Fri Sep 1 21:21:08 2000
@@ -16,5 +16,5 @@
#include
-static __attribute__((unused)) void unused(void)
+static void unused(void)
{
agp_enable(0);
Index: drivers/char/drm/gamma_drv.c
--- drivers/char/drm/gamma_drv.c.prev
+++ drivers/char/drm/gamma_drv.cFri Sep 1 21:21:03 2000
@@ -36,5 +36,5 @@
#include
-static __attribute__((unused)) void unused(void)
+static void unused(void)
{
agp_enable(0);
Index: drivers/char/drm/i810_drv.c
--- drivers/char/drm/i810_drv.c.prev
+++ drivers/char/drm/i810_drv.c Fri Sep 1 21:20:58 2000
@@ -36,5 +36,5 @@
#include
-static __attribute__((unused)) void unused(void)
+static void unused(void)
{
agp_enable(0);
Index: drivers/char/drm/mga_drv.c
--- drivers/char/drm/mga_drv.c.prev
+++ drivers/char/drm/mga_drv.c Fri Sep 1 21:20:52 2000
@@ -37,5 +37,5 @@
#include
-static __attribute__((unused)) void unused(void)
+static void unused(void)
{
agp_enable(0);
Index: drivers/char/drm/r128_drv.c
--- drivers/char/drm/r128_drv.c.prev
+++ drivers/char/drm/r128_drv.c Fri Sep 1 21:20:40 2000
@@ -36,5 +36,5 @@
#include
-static __attribute__((unused)) void unused(void)
+static void unused(void)
{
agp_enable(0);
Index: drivers/char/drm/tdfx_drv.c
--- drivers/char/drm/tdfx_drv.c.prev
+++ drivers/char/drm/tdfx_drv.c Fri Sep 1 21:20:47 2000
@@ -37,5 +37,5 @@
#include
-static __attribute__((unused)) void unused(void)
+static void unused(void)
{
agp_enable(0);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre2: slab.c missing return
The modification of slab.c in 2.2.18pre2 seems to be missing a "return"
in kmem_cache_shrink():
Index: mm/slab.c
--- mm/slab.c.prev
+++ mm/slab.c Fri Sep 1 21:16:45 2000
@@ -1048,5 +1048,5 @@ found:
int kmem_cache_shrink(kmem_cache_t *cachep)
{
- __kmem_cache_shrink(cachep,0);
+ return __kmem_cache_shrink(cachep,0);
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre2
According to David S. Miller: >o Acenic 0.45 fixes (Chip Salzenberg) > > This adds a huge comment claiming to fix some race condition, > but no actual code is changed. How can this be? :-) The bug fix was already in. The log message is misleading. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
According to Bill Rugolsky Jr.: > On Fri, Sep 01, 2000 at 12:05:03PM +0100, Alan Cox wrote: > > Right now Im not happy with the nfsv3 stuff I last looked at and > > it seems to still contain things Linus rejected a while back. > > Alan, would you please describe in a few words what items are > problematic? Yes, please ... without specifics we can't improve the situation. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre2
According to Albert D. Cahalan: > The last time this issue came up, it was discovered that Windows 9x > does not use the same generation rules as Windows NT. Well, making the rules the same as NT would be fine, I suspect. Even better would be a mount option, I think, since there will always be someone with specific compatibility issues. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
According to Bill Rugolsky Jr.: On Fri, Sep 01, 2000 at 12:05:03PM +0100, Alan Cox wrote: Right now Im not happy with the nfsv3 stuff I last looked at and it seems to still contain things Linus rejected a while back. Alan, would you please describe in a few words what items are problematic? Yes, please ... without specifics we can't improve the situation. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre2: fencepost error in __ioremap() [AGP]
The AGP patches add some code to __ioremap. That code seems to me to
have a fencepost error.
In the below hunk, note that temp_end is set to "temp_addr+(size-1)".
It points _at_ the last page to be examined, not beyond it. So the
loop should be controlled by a "=" test, not a "" test. Without
this patch, the last page in the range is not tested for reservation.
Index: arch/i386/mm/ioremap.c
--- arch/i386/mm/ioremap.c.prev
+++ arch/i386/mm/ioremap.c Fri Sep 1 20:11:25 2000
@@ -118,5 +118,5 @@ void * __ioremap(unsigned long phys_addr
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i = MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre2
According to David S. Miller: o Acenic 0.45 fixes (Chip Salzenberg) This adds a huge comment claiming to fix some race condition, but no actual code is changed. How can this be? :-) The bug fix was already in. The log message is misleading. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
According to Paul Gortmaker: > (things marked as not set or modular aren't relevant to the zImage) True, but reconstructing the (b)zImage isn't the only purpose of keeping a config file around. So I'd rather keep the modular settings. But maybe that's just me. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
According to Paul Gortmaker: (things marked as not set or modular aren't relevant to the zImage) True, but reconstructing the (b)zImage isn't the only purpose of keeping a config file around. So I'd rather keep the modular settings. But maybe that's just me. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: Magic patch for older Symbios SCSI
According to Alan Cox: > > Nobody knows why this patch works. (Really!) But it does. (Really!) > > It makes the sym53c8xx driver work even with some very old 53c810 chips. > > Without this patch, the driver hangs on them. This is reproducible > > You arent supposed to use sym53c8xx with old chips but ncr53c8xx Some of our systems are mixed old and new. Making one driver work with both old and new is a significant life-simplification. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
According to Andi Kleen: > You probably don't have a .config.gz that is longer than a page > (4K), because in that case it'll badly corrupt your memory (or you > just haven't noticed the corruption yet ;) Hm... they're all <4K, but a few are pushing it. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Refinements to CONFIG_IP_PNP
P and RARP (not DHCP)
- *off or none - don't do autoconfig at all
+ *off|none - don't do autoconfig at all (DEFAULT)
+ *on|any - use any configured protocol
+ *dhcp|bootp|rarp - use only the specified protocol
+ *both - use both BOOTP and RARP (not DHCP)
*/
static int __init ic_proto_name(char *name)
{
- if (!strcmp(name, "off") || !strcmp(name, "none")) {
- ic_proto_enabled = 0;
+ if (!strcmp(name, "on") || !strcmp(name, "any")) {
return 1;
}
@@ -1242,8 +1306,8 @@ void __init ip_auto_config_setup(char *a
int num = 0;
- if (!strcmp(addrs, "off") || !strcmp(addrs, "none")) {
- ic_enable = 0;
+ ic_enable = (*addrs && strcmp(addrs, "off") && strcmp(addrs, "none"));
+ if (!ic_enable)
return;
- }
+
if (ic_proto_name(addrs))
return;
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Magic patch for older Symbios SCSI
Nobody knows why this patch works. (Really!) But it does. (Really!) It makes the sym53c8xx driver work even with some very old 53c810 chips. Without this patch, the driver hangs on them. This is reproducible Index: drivers/scsi/sym53c8xx.c --- drivers/scsi/sym53c8xx.c.prev +++ drivers/scsi/sym53c8xx.cSat Jun 17 17:49:46 2000 @@ -4792,5 +4792,5 @@ printk(KERN_INFO NAME53C "%s-%d: rev=0x% #define XXX0 #else -#define XXX3 +#define XXX2 #endif np->script0->dataphase[XXX] = cpu_to_scr(SCR_JUMP); -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Support O_NONBLOCK for SCSI disks
Unless I misunderstood Eric Youngdale's reply, he agrees that the
below patch is OK.
Index: drivers/scsi/sd.c
--- drivers/scsi/sd.c.prev
+++ drivers/scsi/sd.c Fri Jun 23 12:50:23 2000
@@ -151,34 +151,41 @@ static int sd_open(struct inode * inode,
* is being re-read.
*/
-
while (rscsi_disks[target].device->busy)
barrier();
-if(rscsi_disks[target].device->removable) {
+
+/*
+ * When opening removable disks, we check media...
+ * ... unless media don't matter, due to O_NONBLOCK.
+ */
+if ( rscsi_disks[target].device->removable
+ && !(filp->f_flags & O_NONBLOCK) )
+{
+/*
+ * Note disk change and/or removal.
+ * Also try to read new partition table (if any).
+ */
check_disk_change(inode->i_rdev);
- /*
-* If the drive is empty, just let the open fail.
-*/
+/*
+ * If the drive is empty, let the open fail.
+ */
if ( !rscsi_disks[target].ready )
- return -ENXIO;
+return -ENXIO;
- /*
-* Similarly, if the device has the write protect tab set,
-* have the open fail if the user expects to be able to write
-* to the thing.
-*/
- if ( (rscsi_disks[target].write_prot) && (filp->f_mode & 2) )
- return -EROFS;
+/*
+ * If the device has the write protect tab set,
+ * let the open fail if the user expects to be able to write.
+ */
+if ( (rscsi_disks[target].write_prot) && (filp->f_mode & 2) )
+return -EROFS;
}
/*
- * It is possible that the disk changing stuff resulted in the device being taken
- * offline. If this is the case, report this to the user, and don't pretend that
- * the open actually succeeded.
+ * It is possible that the disk changing stuff (or something
+ * else?) resulted in the device being taken offline.
+ * If so, let the open fail.
*/
-if( !rscsi_disks[target].device->online )
-{
+if ( !rscsi_disks[target].device->online )
return -ENXIO;
-}
/*
@@ -1069,5 +1076,4 @@ static int check_scsidisk_media_change(k
int target;
struct inode inode;
-int flag = 0;
target = DEVICE_NR(full_dev);
@@ -1121,9 +1127,9 @@ static int check_scsidisk_media_change(k
* struct and tested at open ! Daniel Roche ( [EMAIL PROTECTED] )
*/
-
rscsi_disks[target].ready = 1; /* FLOPTICAL */
retval = rscsi_disks[target].device->changed;
-if(!flag) rscsi_disks[target].device->changed = 0;
+rscsi_disks[target].device->changed = 0;
+
return retval;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: /proc/config.gz
CONFIG
+static struct proc_dir_entry proc_root_config = {
+ PROC_CONFIG, 9, "config.gz",
+ S_IFREG | S_IRUGO, 1, 0, 0,
+ 0, _array_inode_operations
+};
+#endif
__initfunc(void proc_root_init(void))
@@ -771,5 +778,7 @@ __initfunc(void proc_root_init(void))
proc_device_tree_init();
#endif
-
+#ifdef CONFIG_PROC_CONFIG
+ proc_register(_root, _root_config);
+#endif
proc_bus = create_proc_entry("bus", S_IFDIR, 0);
}
Index: init/version.c
--- init/version.c.prev
+++ init/version.c Fri Aug 4 18:52:48 2000
@@ -7,8 +7,12 @@
*/
+#include
#include
#include
#include
#include
+#ifdef CONFIG_PROC_CONFIG
+#include
+#endif
#define version(a) Version_ ## a
Index: scripts/bin2c.c
--- /dev/null Tue May 9 16:53:16 2000
+++ scripts/bin2c.c Fri Aug 4 18:52:48 2000
@@ -0,0 +1,23 @@
+#include
+
+int main(int argc, char *argv[])
+{
+ int ch,total=0;
+
+ if(argc>1) printf("const char *%s %s=\n",argv[1],argc>2?argv[2]:"");
+
+ do {
+ printf("\t\"");
+ while((ch=getchar())!=EOF)
+ {
+ total++;
+ printf("\\x%02x",ch);
+ if(total%16==0) break;
+ }
+ printf("\"\n");
+ } while(ch!=EOF);
+
+ if(argc>1) printf("\t;\n\nconst int %s_size = %d;\n",argv[1],total);
+
+ return 0;
+}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: vfat filename creation rules
} else {
+ res = vfat_valid_longname(name, len, xlate);
+ if (res < 0)
+ return res;
+ res = vfat_create_shortname(dir, name, len, msdos_name, utf8);
+ if (res < 0)
+ return res;
}
- res = vfat_create_shortname(dir, name, len, msdos_name, utf8);
- if (res < 0)
- return res;
return vfat_fill_long_slots(ds, name, len, msdos_name, slots, xlate,
utf8, nls);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Consistency in ext2 error setting
This is a patch from Andreas Dilger <[EMAIL PROTECTED]>.
It claims to fix some corner cases where an error code may not be
returned properly. Here's the description:
--
ext2_bread always sets err to some sane value. I traced this through:
ext2_bread() calls ext2_getblk to set *err or sets *err = -EIO;
ext2_getblk() calls ext2_get_block to set *err;
ext2_get_block() returns 0, -EIO, or {inode,block}_getblk _may_ set err;
The inode_getblk and block_getblk functions themselves do not always set *err,
although err = 0 before they are called from ext2_get_block(), so there is
_always_ a return value set from ext2_get_block().
The ext2_get_block() function may call block_getblk() several times without
checking the return value, so it _appears_ it would overwrite the last error
value. However, one (non-obvious) thing to note is that bh = NULL on error
return* from {inode,block}_getblk(), and calls to block_getblk() are a no-op
if bh == NULL.
(*) There was one (probably very rare) error case where block_getblk()
might return non-NULL: after bforget(result) jumps back to repeat: and
then we get an error with ext2_alloc_block() - we return a bad result.
I also fixed this in the attached patch.
I also found that ext2_alloc_block() did not set a return code in the
(#undef'd) PREALLOC path, and inode_getblk() set a return value instead
of using the error from ext2_alloc_block(). I also verified that
ext2_alloc_block() itself always sets an error code.
--
Index: fs/ext2/balloc.c
--- fs/ext2/balloc.c.prev
+++ fs/ext2/balloc.cSat Jun 17 17:48:19 2000
@@ -479,9 +479,6 @@ repeat:
i = 0;
gdp = ext2_get_group_desc (sb, i, );
- if (!gdp) {
- *err = -EIO;
- unlock_super (sb);
- return 0;
- }
+ if (!gdp)
+ goto io_error;
if (le16_to_cpu(gdp->bg_free_blocks_count) > 0)
break;
Index: fs/ext2/inode.c
--- fs/ext2/inode.c.prev
+++ fs/ext2/inode.c Sat Jun 17 17:48:19 2000
@@ -132,4 +132,5 @@ static int ext2_alloc_block (struct inod
mark_buffer_dirty(bh, 1);
brelse (bh);
+ *err = 0;
} else {
ext2_discard_prealloc (inode);
@@ -207,4 +208,5 @@ int ext2_bmap (struct inode * inode, int
}
+/* must return NULL on error */
static struct buffer_head * inode_getblk (struct inode * inode, int nr,
int create, int new_block, int * err)
@@ -219,5 +221,5 @@ repeat:
tmp = *p;
if (tmp) {
- struct buffer_head * result = getblk (inode->i_dev, tmp,
inode->i_sb->s_blocksize);
+ result = getblk (inode->i_dev, tmp, inode->i_sb->s_blocksize);
if (tmp == *p)
return result;
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Rusty's fasync patch backported
2.2 currently ignores the return value of f_op->fasync().
This patch fixes that oversight.
Index: fs/ioctl.c
--- fs/ioctl.c.prev
+++ fs/ioctl.c Sat Jun 17 17:48:10 2000
@@ -85,6 +85,10 @@ asmlinkage int sys_ioctl(unsigned int fd
if ((flag ^ filp->f_flags) & FASYNC) {
if (filp->f_op && filp->f_op->fasync)
- filp->f_op->fasync(fd, filp, on);
+ error = filp->f_op->fasync(fd, filp, on);
+ else error = -ENOTTY;
}
+ if (error != 0)
+ break;
+
if (on)
filp->f_flags |= FASYNC;
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2 vs. CAP_CHOWN and CAP_FOWNER
CAP_CHOWN relaxes the BSD-style restrictions on chowning a file to a
user id other than yourself (a restriction instituted to enforce
quotas).
CAP_FOWNER relaxes the normal restriction on performing operations on
files that belong to someone other than yourself.
This patch corrects the implementation of these capabilities.
Index: fs/attr.c
--- fs/attr.c.prev
+++ fs/attr.c Tue Aug 29 18:02:40 2000
@@ -23,18 +23,22 @@ int inode_change_ok(struct inode *inode,
/* Make sure a caller can chown. */
- if ((ia_valid & ATTR_UID) &&
- (current->fsuid != inode->i_uid ||
-attr->ia_uid != inode->i_uid) && !capable(CAP_CHOWN))
- goto error;
+ if ((ia_valid & ATTR_UID) && attr->ia_uid != inode->i_uid) {
+ if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
+ goto error;
+ if (current->fsuid != attr->ia_uid && !capable(CAP_CHOWN))
+ goto error;
+ }
/* Make sure caller can chgrp. */
- if ((ia_valid & ATTR_GID) &&
- (!in_group_p(attr->ia_gid) && attr->ia_gid != inode->i_gid) &&
- !capable(CAP_CHOWN))
- goto error;
+ if ((ia_valid & ATTR_GID) && attr->ia_gid != inode->i_gid) {
+ if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
+ goto error;
+ if (!in_group_p(attr->ia_gid) && !capable(CAP_CHOWN))
+ goto error;
+ }
/* Make sure a caller can chmod. */
if (ia_valid & ATTR_MODE) {
- if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER))
+ if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
goto error;
/* Also check the setgid bit! */
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
