[PATCH] 0 byte writes should not seek even with O_APPEND
Hi Linus,
Currently when a zero byte write is done on a regular file
opened with O_APPEND the file offset is set to the end of the
file. For POSIX compliant behaviour this shouldn't happen.
The attached patch fixes this.
Chris.
--- mm/filemap.c.orig Mon Nov 20 14:05:38 2000
+++ mm/filemap.cMon Nov 20 18:11:43 2000
@@ -2458,12 +2458,15 @@
}
}
- status = 0;
- if (count) {
- remove_suid(inode);
- inode->i_ctime = inode->i_mtime = CURRENT_TIME;
- mark_inode_dirty(inode);
+ if (count == 0) {
+ err = 0;
+ goto out;
}
+
+ status = 0;
+ remove_suid(inode);
+ inode->i_ctime = inode->i_mtime = CURRENT_TIME;
+ mark_inode_dirty(inode);
while (count) {
unsigned long bytes, index, offset;
-
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,RFC] initrd vs. BLKFLSBUF
Werner, Thanks for fix. Applied the patch and it's working now. Linus, please add this patch to the kernel source codes for 2.4.0. Under 2.2.18, it's working fine without the patch. Thanks, Jeff [ [EMAIL PROTECTED] ] - Original Message - From: "Werner Almesberger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, November 20, 2000 11:21 AM Subject: [PATCH,RFC] initrd vs. BLKFLSBUF Hi Al, Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk that was obtained via initrd. I think the problem is that the effect of the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that seems to solve the problem. Since I'm not quite sure I understand the reference counting rules there, I would appreciate your comment. Thanks, - Werner -- cut here --- --- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000 +++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000 @@ -690,6 +690,7 @@ done: if (infile.f_op->release) infile.f_op->release(inode, &infile); + blkdev_put(out_inode->i_bdev, BDEV_FILE); set_fs(fs); return; free_inodes: /* free inodes on error */ -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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] 36 bit MTRRs (fix for some big memory machines)
Hi, Linus! Will you consider applying the following patchset? You will find it at ftp://ftp.externet.hu/pub/people/zboszor/mtrr-new2.tar.gz I know that you like plain text patches inlined in the mail but I do not know how to get pine to inline the (plain text) attachments... Here is the README from the package: This patchset contains fixes and enhancements for mtrr.c, the patches are against 2.4.0-test11-pre5 and should be applied in the following order: 1. mtrr-vs-new-cpuid.diff This is David Wragg's 36 bit MTRR patch (so big memory machines do not slow down) updated for HPA's new CPUID code. 2. mtrr-x86-64.diff This allows the AMD Hammer to use its 40 (or more) bits wide MTRRs using the phyical address width query feature. 3. mtrr-sizefix.diff This fixes a problem: do not allow wider base/size parameters than the arch could handle. (E.g. my PIII happily accepted and MTRR entry with 4GB size starting at 64 GB - since the base was correctly masked, the result was a 4GB MTRR starting at 0. 4. mtrr-page.diff David's patch changed mtrr.c's internal functions to pass the base and size parameters in page granular units. This patch exposes this feature in the kernel, providing mtrr_add_page() and mtrr_del_page(). 5. mtrr-proc.diff This enables setting MTRRs above 4GB through /proc/mtrr. (To achieve this, I had to add simple_strtoull() to lib/vsprintf.c.) 6. mtrr-ioctl.diff This enables setting MTRRs above 4GB through ioctls. It is very likely that if you leave out one patch, the next ones will not apply. (There will be rejects.) I discussed these changes with David Wragg, he blessed it. :-) Three notes, though: This patchset was tested on Athlon, PPro (by David Wragg), dual PIII and dual Celeron machines. (by me) Patch #3 tries to correctly handle those CPUs where the MTRRs/ARRs/MCRs are 32 bit wide. Patch #5 _required_ 64 bit arithmetics, but egcs-1.1.2 seems to handle this correctly. Regards, Zoltan Boszormenyi <[EMAIL PROTECTED]> - 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.4.0-test11
On Sun, 19 Nov 2000, Linus Torvalds wrote: > - Asit Mallick: enable the APIC in the official order What is this intended to fix? Please revert it -- it breaks for i82489DX APICs configured to the PIC mode upon boot -- local interrupt registers are hardwired to 0x0001 and cannot be changed when a local APIC is in the software-disabled state (i.e. bit 8 of the spurious interrupt vector register is cleared). As a result no local interrupts get configured. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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/
easy-to-fix bug in /dev/null driver
It seems to me that this code in linux/drivers/char/mem.c
is a bug:
===
static ssize_t write_null(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
return count;
}
===
To activate the bug try this little program:
---
#include
#include
#include
main() {
char buf[1];
int fd = open("/dev/null", O_RDWR);
int i;
printf("fd = %d\n", fd);
for (i = 1; i <= 10; ++i) {
int ret = write(fd, buf, -i);
if (ret < 0) {
fprintf(stderr, "i = %d, errno = %d\n", i, errno);
perror("write");
}
}
}
---
On my legacy 2.4.0-test1-ac21 system, I get this:
---
fd = 3
i = 1, errno = 1
write: Operation not permitted
i = 2, errno = 2
write: No such file or directory
i = 3, errno = 3
write: No such process
i = 4, errno = 4
write: Interrupted system call
i = 5, errno = 5
write: Input/output error
i = 6, errno = 6
write: Device not configured
i = 7, errno = 7
write: Argument list too long
i = 8, errno = 8
write: Exec format error
i = 9, errno = 9
write: Bad file descriptor
i = 10, errno = 10
write: No child processes
---
You could argue that user-space users shouldn't do such stupid
things, but in some contexts, the bug might be hard to find,
and having wrong error messages just makes such bugs hard to find.
Arguably, write() should not be defined to return the count of
written bytes when this is impossible for very large writes.
I.e. it is the definition of the user-space write() function which
is meaningless for large counts - so why bother to permit this
if a negative error code is returned when this is attempted?
Perhaps more correct code for the write_null function would be:
===
static ssize_t write_null(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
if ((ssize_t)count >= 0)
return (ssize_t)count;
else
return 0x7fff;
}
===
with preferably a symbol instead of 0x7fff.
Cheers,
Alan Kennington.
name: Dr. Alan Kennington
e-mail: [EMAIL PROTECTED]
website: http://topology.org/
city: Adelaide, South Australia
coords: 34.88051 S, 138.59334 E
timezone: UTC+1030 http://topology.org/timezone.html
pgp-key: http://topology.org/key_ak2.asc
-
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/
user-mode port 0.34-2.4.0-test11
The user-mode port of 2.4.0-test11 is available. UML is now able to run as a daemon, i.e. with no stdin/stdout/stderr. The hostfs filesystem now works as a readonly filesystem. It's now configurable. I'm using it as a module. It ought to work compiled into the kernel, but I haven't checked this. I fixed a number of bugs. NOTE: If you compile from source, you must put 'ARCH=um' on the make command line or in the environment, like: make linux ARCH=um or ARCH=um make linux or export ARCH=um make linux This is because I've changed the top-level Makefile to build either a native kernel or a usermode kernel, with the default being native. This is in preparation for submitting this port to the main pool. The ARCH calculation is now this: # SUBARCH tells the usermode build what the underlying arch is. That is set # first, and if a usermode build is happening, the "ARCH=um" on the command # line overrides the setting of ARCH below. If a native build is happening, # then ARCH is assigned, getting whatever value it gets normally, and # SUBARCH is subsequently ignored. SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/) ARCH := $(SUBARCH) If anyone has any objections to this going in the main pool, let me know, and also let me know what you would suggest as a fix. The project's home page is http://user-mode-linux.sourceforge.net The project's download page is http://sourceforge.net/project/filelist.php?grou p_id=429 Jeff - 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: ext2 sparse superblocks
Michael Rothwell write: > I'm looking for documentation on Ext2's support for sparse superblocks. > What it the method uses to reduce the number of superblocks? How are > they laid out before vs after sparse_super is enabled? Any caveats? In an old-style (non-sparse) filesystem, every block group has a superblock copy. Only the superblock in the first group is used in normal cases. In a sparse filesystem, superblock copies are in groups 0, 1 and ones that are powers of 3, 5, and 7. The primary superblock is in group 0, and backups are in groups 1, 3, 5, 7, 9, 25, 27, 49, 81, 125, etc. This greatly reduces the number of superblock copies stored in large filesystems. What is actually more important is that group descriptor backups are only stored in the "sparse" groups as well. Because the group descriptor table grows with the size of the filesystem, if there is a backup copy in each group (as with the old non-sparse layout) it would eventually fill the entire filesystem. For a 1kB block non-sparse ext2 filesystem, this happens at 2TB - basically the entire filesystem is full with metadata, and no room to put any regular data. For a 4kB block filesystem, this would happen at 524 TB. With sparse filesystems, the metadata will only take a small percentage of the available space. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: run level 1, login takes too long, 2.4.X vs. 2.2.X
Hi David, Yup, I know rpc.portmap isn't running, the point is that it wasn't running on either 2.2.17 or 2.4.X. Isn't run level 1 supposed to only be the bare minimum of running processes, a few kernel processes, init and getty. No network services... What's changed in the kernel to elicit this behavior? Is there a better "faster" way to get root access at run level 1 w/o login & passwd on 2.4.X? No it's not an everyday occurance, but I was impatiently thinking the sytem had locked up and rebooted a couple of times, so it got me wondering why 2.2.X and 2.4.X differ in this basic behavior. Martin David Ford wrote: > > rpc.portmap isn't running, your login configuration/nss requires yp or something >provided ans an RPC. > > -d > > "M.H.VanLeeuwen" wrote: > > > I had occasion to "telinit 1" today and found that it took a long time > > to login after root passwd was entered. this doesn't happen with 2.2.X > > kernels. > > > > Is this to be expected with the 2.4 series kernels? or a bug? > > > > Martin - 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: NCPFS not returning Volume Size (???)
On Sun, Nov 19, 2000 at 05:10:06PM +0100, Petr Vandrovec wrote:
> On Thu, Nov 16, 2000 at 08:40:29PM -0700, Jeff V. Merkey wrote:
> > Petr,
> >
> > NCPFS in 2.2.18-pre21 is not returning volume size via df -h. I checked
> > your code and found this comment:
> >
> > static int ncp_statfs(struct super_block *sb, struct statfs *buf, int bufsiz)
> > {
> > NCP Code
> >
> > /17E6 Get Object's Remaining Disk Space
> >
> > I noticed that 2.4 also is not reporting Volume free space.
>
> Yes, it is intentional. There are two different things:
> (1) you can mount all volumes from server to one mountpoint, and all these
> volumes share one superblock. So it is not clear, which value to
> return. Sum of all volume sizes?
> (2) in Netware, each directory can have its own space limit, so
> returned free space should differ from directory to directory.
> As statfs is per-superblock thing, I believe that returning
> 'sorry, I do not know' is better.
>
> > grouped into case/switch classes. If you can point me to
> > where 1) the login ID is stored and B) where NCP packet
> > request/reponse headers are constructed, i.e. a skeleton
> > to send/receive the requests I can grab, I'll try to
> > code this for you.
>
> loginID is not stored anywhere in kernel. You can look at
> ioctl(,NCP_IOC_GETOBJECTNAME,...). If you need your own ID
> so you know which disk space restriction retrieve, you'll have
> to first execute retrieve logged in info for current connection
> (where connection number is stored in server->connection).
>
> request/reply is built in preallocated space, you can look
> at functions in ncplib_kernel.c, f.e. ncp_open_create_file_or_subdir
> uses almost every of ncp_add_* functions. ncp_request() then
> executes RPC call and ncp_unlock_server() unlocks connection.
> You must NOT access userspace between ncp_init_request()
> and ncp_unlock_server() function, or deadlock can occur.
>
There's is a method to obtain this accurately. NSS may have
changed some things. I have a list of four issues now with this
one I need to get finished. I may need some help with your code
as I go.
Jeff
> Best regards,
> Petr Vandrovec
> [EMAIL PROTECTED]
-
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.18pre22
On Sun, Nov 19, 2000 at 04:09:01PM +0100, Kai Germaschewski wrote:
> On Sun, 19 Nov 2000, Jeff V. Merkey wrote:
>
> > > o Small ISDN documentation fixes (Kai Germaschewski)
> >
> > Alan, On the ISDN issue, isdn4K-utils seems to be out of sync with
> > kernels older than 2.2.16. Some #define's that used to be in
> > the 2.2.14 patch don't seem to be in 2.2.17 >. At present, requires
> > an ugly .config patch to work under 2.2.18-21.
>
> It'ld be nice if you at least CC'ed your mail to the maintainers, i.e. the
> isdn4linux people, because not everyone has the time to follow l-k.
> Any way, I CC'ed [EMAIL PROTECTED] now, and this thread
> should continue there.
>
> Could you please clarify which problems you have? You state that the utils
> seem to be out of sync with kernels < 2.2.16, but you need to patch them
> for kernels > 2.2.17 ?
>
> I just tried the latest "release" of the utils,
> isdn4k-utils.v3.1pre1.tar.gz, and the current CVS version against
> 2.2.18pre22, and they compile fine. Note that binary compatibility didn't
> break during 2.2, only for 2.4. (I.e. utils compiled on 2.2 will complain
> if used with 2.4, utils compiled on 2.4 will work on either kernel series)
ISDN_MODEM_ANZREG undefined on 2.4.0-10(11) and 2.2.18-22, rpm.spec is
attached.
Jeff
Summary: Utilities for configuring an ISDN subsystem.
Name: isdn4k-utils
Version: 3.1
Release: 1
Copyright: GPL
Group: Applications/System
Source0:
ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/testing/isdn4k-utils.v3.1beta7.tar.gz
Patch0: isdn4k-utils.patch
Patch1: isdn4k-utils-ipppd.patch
BuildRoot: /var/tmp/%name-root
Requires: initscripts >= 4.93
Prereq: /sbin/chkconfig
Vendor: Timpanogas Research Group, Inc.
Packager: [EMAIL PROTECTED]
%description
The isdn4k-utils package contains a collection of utilities needed for
configuring an ISDN subsystem.
%package -n xisdnload
Version: 1.38
Summary: An ISDN connection load average display for the X Window System.
Group: Applications/System
Requires: isdn4k-utils
%description -n xisdnload
The xisdnload utility displays a periodically updated histogram of the
load average over your ISDN connection.
%prep
%setup -q -n isdn4k-utils
%patch0
%patch1
cd capi20
libtoolize --copy --force
test -f /usr/include/capi20.h || cp capi20.h /usr/include/capi20.h
cd ..
%build
cp .config.rpm .config
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" subconfig
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/dev
mkdir -p $RPM_BUILD_ROOT/etc/rc.d/init.d
mkdir -p $RPM_BUILD_ROOT/etc/{ppp,isdn}
mkdir -p $RPM_BUILD_ROOT/var/{log/vbox,spool/vbox,lock/isdn}
mkdir -p $RPM_BUILD_ROOT/usr/{sbin,X11R6/bin}
chmod 1777 $RPM_BUILD_ROOT/var/spool/vbox
make install DESTDIR=$RPM_BUILD_ROOT
mv -fv $RPM_BUILD_ROOT/usr/bin/x* $RPM_BUILD_ROOT/usr/X11R6/bin/
mv -fv $RPM_BUILD_ROOT/usr/man/man1/x* $RPM_BUILD_ROOT/usr/X11R6/man/man1/
touch $RPM_BUILD_ROOT/etc/ppp/ioptions
test -f $RPM_BUILD_ROOT/etc/isdn/isdn.conf.new && \
mv -f $RPM_BUILD_ROOT/etc/isdn/isdn.conf.new $RPM_BUILD_ROOT/etc/isdn/isdn.conf
strip $RPM_BUILD_ROOT/usr/bin/* $RPM_BUILD_ROOT/usr/sbin/* \
$RPM_BUILD_ROOT/usr/X11R6/bin/* || :
# build some more documentation
pushd FAQ/tutorial ; {
sgml2txt EN-i4l.sgml
sgml2html EN-i4l.sgml
} ; popd
chmod 0755 $RPM_BUILD_ROOT/usr/bin/vboxbeep
%post
test -f /dev/isdnctrl || ln -sf isdnctrl0 /dev/isdnctrl
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%dir /etc/isdn
%dir /var/spool/vbox
%dir /var/log/vbox
%verify(not md5 size mtime) %config(noreplace) /etc/isdn/*
/etc/ppp/ioptions
/usr/bin/*
/usr/include/*
/usr/lib/*.a
/usr/lib/*.so.*
/usr/man/man?/*
/usr/sbin/*
%doc COPYING HOWTO README
%lang(de) %doc vbox/doc/de/vbox.sgml vbox/doc/de/vbox.txt
%doc FAQ/tutorial/EN-i4l* FAQ/i4lfaq* Mini-FAQ/* FAQ/_howto/* FAQ/_example/*
#%lang(de) %doc FAQ/out/de-i4l-faq.asc FAQ/out/de-i4l-faq.html
%doc FAQ/_howto FAQ/_example FAQ/tutorial/*.txt FAQ/tutorial/*.html
%files -n xisdnload
%defattr(-,root,root)
/usr/X11R6/bin/xisdnload
%attr(0755,root,root) /usr/X11R6/bin/xmonisdn
/usr/X11R6/lib/X11/app-defaults/*
/usr/X11R6/man/man1/*
/usr/X11R6/include/X11/bitmaps/*
%doc xmonisdn/README
%changelog
Re: Linux 2.2.18pre22
On Sun, Nov 19, 2000 at 12:57:35PM +, Alan Cox wrote: > > > o Small ISDN documentation fixes (Kai Germaschewski) > > > > Alan, On the ISDN issue, isdn4K-utils seems to be out of sync with=20 > > kernels older than 2.2.16. Some #define's that used to be in > > the 2.2.14 patch don't seem to be in 2.2.17 >. At present, requires > > an ugly .config patch to work under 2.2.18-21. =20 > > Shouldn't do. ISDN has changed between 2.2.16 and 2.2.18pre22 but not in any > way I am aware is bad. 2.2.19 has the merge of the rest of the isdn changes > queued. The Latest tar.gz in isdn4k-utils.src.rpm will not build. I went to ftp.isdn4linux.de and found the latest they have posted and the following errors are reported from the build. Against 2.4.0-10(11) isdn4k-utils-v3.1pre1.tar.gz ISDN_MODEM_ANZREG is undeclared in usr/src/linux/include/ Against 2.2.18-22same same problem Jeff > - 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: BTTV detection broken in 2.4.0-test11-pre5
David Ford <[EMAIL PROTECTED]> wrote: >> Please turn this off. >> >My vcard size is the same or smaller than the average signature. Using mime, you >have the option of easily filtering vcards. Signatures aren't as easily >identified for filtering. I think the complaint was due not to the size but to the fact that vcards come through as attachments, whereas signatures are usually plain text. Some of us think attachments of any kind (or anything other than plain text) on mailing lists are Bad Things. - 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: run level 1, login takes too long, 2.4.X vs. 2.2.X
rpc.portmap isn't running, your login configuration/nss requires yp or something provided ans an RPC. -d "M.H.VanLeeuwen" wrote: > I had occasion to "telinit 1" today and found that it took a long time > to login after root passwd was entered. this doesn't happen with 2.2.X > kernels. > > Is this to be expected with the 2.4 series kernels? or a bug? > > Martin begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
RE: videodev.c won't compile in test11-pre6/pre7/final
Hello,
The undeclared variables are defined in include/linux/videodev.h , which is included
in videodev.c .
...
#define VID_TYPE_SUBCAPTURE 512
#define VID_TYPE_MPEG_DECODER 1024
#define VID_TYPE_MPEG_ENCODER 2048
#define VID_TYPE_MJPEG_DECODER 4096
#define VID_TYPE_MJPEG_ENCODER 8192
...
Regards,
Frank
--On Sunday, November 19, 2000 9:43 PM -0500 Ari Pollak <[EMAIL PROTECTED]> wrote:
> I was going to report this back in pre6, but I thought someone had
> caught it already.. When the bttv driver is enbabled as a module in
> test11, make modules fails with:
>
> videodev.c: In function `videodev_proc_read':
> videodev.c:283: `VID_TYPE_MPEG_DECODER' undeclared (first use in this
> function)
> videodev.c:283: (Each undeclared identifier is reported only once
> videodev.c:283: for each function it appears in.)
> videodev.c:284: `VID_TYPE_MPEG_ENCODER' undeclared (first use in this
> function)
> videodev.c:285: `VID_TYPE_MJPEG_DECODER' undeclared (first use in this
> function)videodev.c:286: `VID_TYPE_MJPEG_ENCODER' undeclared (first use
> in this function)videodev.c: In function
> `video_register_device_Re1d5d9de':
> videodev.c:475: structure has no member named `devfs_handle'
> videodev.c:476: warning: implicit declaration of function
> `devfs_register_R346f2926'
> videodev.c:476: `DEVFS_FL_DEFAULT' undeclared (first use in this
> function)
> videodev.c: In function `video_unregister_device_R0e30839e':
> videodev.c:510: warning: implicit declaration of function
> `devfs_unregister_Rb8aa48ae'
> videodev.c:510: structure has no member named `devfs_handle'
> videodev.c: In function `videodev_init':
> videodev.c:538: warning: implicit declaration of function
> `devfs_register_chrdev_R46ccf2d8'
> videodev.c: In function `cleanup_module':
> videodev.c:572: warning: implicit declaration of function
> `devfs_unregister_chrdev_R77f3e0ce'
> {standard input}: Assembler messages:
> {standard input}:8: Warning: Ignoring changed section attributes for
> .modinfo
> make[3]: *** [videodev.o] Error 1
> make[3]: Leaving directory `/usr/src/linux/drivers/media/video'
> -
> 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/
-
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,RFC] initrd vs. BLKFLSBUF
Hi Al, Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk that was obtained via initrd. I think the problem is that the effect of the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that seems to solve the problem. Since I'm not quite sure I understand the reference counting rules there, I would appreciate your comment. Thanks, - Werner -- cut here --- --- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000 +++ linux/drivers/block/rd.cMon Nov 20 04:03:42 2000 @@ -690,6 +690,7 @@ done: if (infile.f_op->release) infile.f_op->release(inode, &infile); + blkdev_put(out_inode->i_bdev, BDEV_FILE); set_fs(fs); return; free_inodes: /* free inodes on error */ -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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: BTTV detection broken in 2.4.0-test11-pre5
On Sun, 19 Nov 2000, Rogier Wolff wrote: > Someone wrote: > > > > So change the CMOS-settings so that the BIOS changes the boot order > > > > from A, C, CD-ROM to C first instead. *grin* How long do you want > > > > to keep playing Tic-Tac-Toe? > > > Writeprotect the flashbios with the motherboard jumper, and remove the > > > cmos battery. > The "writeprotect flashbios" usually only protects the bottom 8k of > the CMOS. That's the part that you still need to boot the system to > reflash it should somehow your flash be nuked. The writeprotect jumper on all motherboards ive seen physically prevent erase/program voltages from reaching the flash chip (usually pin 1, Vpp). This is why enabling writeprotect jumper on motherboards also prevents the ECSD area from being updated (which is outside the bottom 8k bootblock). -Dan - 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: BTTV detection broken in 2.4.0-test11-pre5
On Mon, 20 Nov 2000, David Woodhouse wrote: > On Sun, 19 Nov 2000, Dan Hollis wrote: > > Writeprotect the flashbios with the motherboard jumper, and remove the > > cmos battery. > > Checkmate. :-) > Only if you run your kernel XIP from the flash. If you load it into RAM, > it's still possible for an attacker to modify it. You can load new code > into the kernel even if the kernel doesn't make it easy for you by having > CONFIG_MODULES defined. The original assertion made was that a script kiddie could modify the kernel so you wouldnt be able to detect a rooted box even after a reboot. What I posted would stop that cold, 100%. Boot from writeprotected floppy, writeprotect the flashbios, and remove the cmos battery. -Dan - 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: run level 1, login takes too long, 2.4.X vs. 2.2.X
On Sun, Nov 19, 2000 at 04:42:03PM -0600, M.H.VanLeeuwen wrote: > I had occasion to "telinit 1" today and found that it took a long time > to login after root passwd was entered. this doesn't happen with 2.2.X > kernels. > > Is this to be expected with the 2.4 series kernels? or a bug? It looks like login is trying to contact a YP server but getting no response. Was the kernel the only configuration detail you modified? Jeff - 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/
videodev.c won't compile in test11-pre6/pre7/final
I was going to report this back in pre6, but I thought someone had
caught it already.. When the bttv driver is enbabled as a module in
test11, make modules fails with:
videodev.c: In function `videodev_proc_read':
videodev.c:283: `VID_TYPE_MPEG_DECODER' undeclared (first use in this
function)
videodev.c:283: (Each undeclared identifier is reported only once
videodev.c:283: for each function it appears in.)
videodev.c:284: `VID_TYPE_MPEG_ENCODER' undeclared (first use in this
function)
videodev.c:285: `VID_TYPE_MJPEG_DECODER' undeclared (first use in this
function)videodev.c:286: `VID_TYPE_MJPEG_ENCODER' undeclared (first use
in this function)videodev.c: In function
`video_register_device_Re1d5d9de':
videodev.c:475: structure has no member named `devfs_handle'
videodev.c:476: warning: implicit declaration of function
`devfs_register_R346f2926'
videodev.c:476: `DEVFS_FL_DEFAULT' undeclared (first use in this
function)
videodev.c: In function `video_unregister_device_R0e30839e':
videodev.c:510: warning: implicit declaration of function
`devfs_unregister_Rb8aa48ae'
videodev.c:510: structure has no member named `devfs_handle'
videodev.c: In function `videodev_init':
videodev.c:538: warning: implicit declaration of function
`devfs_register_chrdev_R46ccf2d8'
videodev.c: In function `cleanup_module':
videodev.c:572: warning: implicit declaration of function
`devfs_unregister_chrdev_R77f3e0ce'
{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for
.modinfo
make[3]: *** [videodev.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/media/video'
-
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.4.0-test11
On Sun, 19 Nov 2000, Rich Baum wrote: > > The patch is in the v2.3 directory. You may want to move it to the > v2.4 directory so people can find it easier. Oops. Thanks. Done. Linus - 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.4.0-test11
The patch is in the v2.3 directory. You may want to move it to the v2.4 directory so people can find it easier. On 19 Nov 2000, at 18:19, Linus Torvalds wrote: > > Ok, test11 is out there. The most noticeable fixes since pre7 are the > Athlon lockup fix, the PCI routing handling, and getting the Joliet stuff > right for iso9660. > > Linus > > > > - final: > - Patrick Mochel: export the ACPI facs table in /proc too > - Brian Gerst: Video4Linux cleanup (named initializers) > - me: only use irq13 for FP errors for external FPU's. This > fixes the Atlon FP exception lockups. > - me: add a new intel signature to the PIRQ table matching logic. > Make the matching match both reported and actual device ID (with a > preference for the reported). Fixes PCMCIA on NEC Versa laptops. > - iso9660: fix Joliet filename argument order bug introduced in pre7 > - Highmem: p_page -> b_page typo. > - me: don't allow pending FPU exceptions without an FPU context.. > > - pre7: > - Kai Germaschewski: more ISDN cleanups and small fixes. > - Al Viro: fix ntfs_new_inode() that he broke. Cleanups. > - various: handle !CONFIG_HOTPLUG properly > - David Miller: sparc and networking > - me: more iso9660 fixes. > - Neil Brown: fix rd and RAID on highmem machines > - Vojtech Pavlik: input driver fixes > - David Woodhouse: module unload races - up_and_exit() > > - pre6: > - Intel: start to add Pentium IV specific stuff (128-byte cacheline > etc) > - David Miller: search-and-destroy places that forget to mark us > running after removing us from a wait-queue. > - me: NFS client write-back ref-counting SMP instability. > - me: fix up non-exclusive waiters > - Trond Myklebust: Be more careful about SMP in NFS and RPC code > - Trond Myklebust: inode attribute update race fix > - Charles White: don't do unaligned accesses in cpqarray driver. > - Jeff Garzik: continued driver cleanup and fixes > - Peter Anvin: integrate more of the Intel patches. > - Robert Love: add i815 signature to the intel AGP support > - Rik Faith: DRM update to make it easier to sync up 2.2.x > - David Woodhouse: make old 16-bit pcmcia controllers work > again (ie i82365 and TCIC) > > - pre5: > - Rasmus Andersen: add proper "" for sound drivers > - David Miller: sparc64 and networking updates > - David Trcka: MOXA numbering starts from 0, not 1. > - Jeff Garzik: sysctl.h standalone > - Dag Brattli: IrDA finishing touches > - Randy Dunlap: USB fixes > - Gerd Knorr: big bttv update > - Peter Anvin: x86 capabilities cleanup > - Stephen Rothwell: apm initcall fix - smp poweroff should work > - Andrew Morton: setscheduler() spinlock ordering fix > - Stephen Rothwell: directory notification documentation > - Petr Vandrovec: ncpfs capabilities check cleanup > - David Woodhouse: fix jffs to use generic is() library > - Chris Swiedler: oom_kill selection fix > - Jens Axboe: re-merge after sleeping in ll_rw_block. > - Randy Dunlap: USB updates (pegasus and ftdi_sio) > - Kai Germaschewski: ISDN ppp header compression fixed > > - pre4: > - Andrea Arcangeli: SMP scheduler memory barrier fixup > - Richard Henderson: fix alpha semaphores and spinlock bugs. > - Richard Henderson: clean up the file from hell: "xor.c" > > - pre3: > - James Simmons: vgacon "printk()" deadlock with global irq lock. > - don't poke blanked console on console output > - Ching-Ling: get channels right on ALI audio driver > - Dag Brattli and Jean Tourrilhes: big IrDA update > - Paul Mackerras: PPC updates > - Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin > serial converter. > - Jeff Garzik: pcnet32 and lance net driver fix/cleanup > - Mikael Pettersson: clean up x86 ELF_PLATFORM > - Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and > cleanups > - Al Viro: Jeff missed some kmap()'s. sysctl cleanup > - Kai Germaschewski: ISDN updates > - Alan Cox: SCSI driver NULL ptr checks > - David Miller: networking updates, exclusive waitqueues nest properly, > SMP i_shared_lock/page_table_lock lock order fix. > > - pre2: > - Stephen Rothwell: directory notify could return with the lock held > - Richard Henderson: CLOCKS_PER_SEC on alpha. > - Jeff Garzik: ramfs and highmem: kmap() the page to clear it > - Asit Mallick: enable the APIC in the official order > - Neil Brown: avoid rd deadlock on io_request_lock by using a > private rd-request function. This also avoids unnecessary > request merging at this level. > - Ben LaHaise: vmalloc threadign and overflow fix > - Randy Dunlap: USB updates (plusb driver). PCI cacheline size. > - Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1 > - Alan Cox: various (At
Re: Freeze on FPU exception with Athlon
=?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> said: > --- Linus Torvalds <[EMAIL PROTECTED]> schrieb: > [...] > > Markus, can you make the irq13 test the first thing > > - don't worry about > > 3dnow as that seems to not be a deciding factor.. > Ok, that was it! It's IRQ 13. Guess I should have > tried that first. Now everything works perfectly. Could you _please_ document this somewhere in the source, so noone trips over this or starts wondering? > Thanks everybody. Nodz. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: Freeze on FPU exception with Athlon
=?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> said: [...] > I will also try to compile a non AMD specific kernel > and see if that makes a difference. If just this 40GB > drive would fsck faster :) mount -o remount,ro [...] -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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/
Linux 2.4.0-test11
Ok, test11 is out there. The most noticeable fixes since pre7 are the Athlon lockup fix, the PCI routing handling, and getting the Joliet stuff right for iso9660. Linus - final: - Patrick Mochel: export the ACPI facs table in /proc too - Brian Gerst: Video4Linux cleanup (named initializers) - me: only use irq13 for FP errors for external FPU's. This fixes the Atlon FP exception lockups. - me: add a new intel signature to the PIRQ table matching logic. Make the matching match both reported and actual device ID (with a preference for the reported). Fixes PCMCIA on NEC Versa laptops. - iso9660: fix Joliet filename argument order bug introduced in pre7 - Highmem: p_page -> b_page typo. - me: don't allow pending FPU exceptions without an FPU context.. - pre7: - Kai Germaschewski: more ISDN cleanups and small fixes. - Al Viro: fix ntfs_new_inode() that he broke. Cleanups. - various: handle !CONFIG_HOTPLUG properly - David Miller: sparc and networking - me: more iso9660 fixes. - Neil Brown: fix rd and RAID on highmem machines - Vojtech Pavlik: input driver fixes - David Woodhouse: module unload races - up_and_exit() - pre6: - Intel: start to add Pentium IV specific stuff (128-byte cacheline etc) - David Miller: search-and-destroy places that forget to mark us running after removing us from a wait-queue. - me: NFS client write-back ref-counting SMP instability. - me: fix up non-exclusive waiters - Trond Myklebust: Be more careful about SMP in NFS and RPC code - Trond Myklebust: inode attribute update race fix - Charles White: don't do unaligned accesses in cpqarray driver. - Jeff Garzik: continued driver cleanup and fixes - Peter Anvin: integrate more of the Intel patches. - Robert Love: add i815 signature to the intel AGP support - Rik Faith: DRM update to make it easier to sync up 2.2.x - David Woodhouse: make old 16-bit pcmcia controllers work again (ie i82365 and TCIC) - pre5: - Rasmus Andersen: add proper "" for sound drivers - David Miller: sparc64 and networking updates - David Trcka: MOXA numbering starts from 0, not 1. - Jeff Garzik: sysctl.h standalone - Dag Brattli: IrDA finishing touches - Randy Dunlap: USB fixes - Gerd Knorr: big bttv update - Peter Anvin: x86 capabilities cleanup - Stephen Rothwell: apm initcall fix - smp poweroff should work - Andrew Morton: setscheduler() spinlock ordering fix - Stephen Rothwell: directory notification documentation - Petr Vandrovec: ncpfs capabilities check cleanup - David Woodhouse: fix jffs to use generic is() library - Chris Swiedler: oom_kill selection fix - Jens Axboe: re-merge after sleeping in ll_rw_block. - Randy Dunlap: USB updates (pegasus and ftdi_sio) - Kai Germaschewski: ISDN ppp header compression fixed - pre4: - Andrea Arcangeli: SMP scheduler memory barrier fixup - Richard Henderson: fix alpha semaphores and spinlock bugs. - Richard Henderson: clean up the file from hell: "xor.c" - pre3: - James Simmons: vgacon "printk()" deadlock with global irq lock. - don't poke blanked console on console output - Ching-Ling: get channels right on ALI audio driver - Dag Brattli and Jean Tourrilhes: big IrDA update - Paul Mackerras: PPC updates - Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin serial converter. - Jeff Garzik: pcnet32 and lance net driver fix/cleanup - Mikael Pettersson: clean up x86 ELF_PLATFORM - Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and cleanups - Al Viro: Jeff missed some kmap()'s. sysctl cleanup - Kai Germaschewski: ISDN updates - Alan Cox: SCSI driver NULL ptr checks - David Miller: networking updates, exclusive waitqueues nest properly, SMP i_shared_lock/page_table_lock lock order fix. - pre2: - Stephen Rothwell: directory notify could return with the lock held - Richard Henderson: CLOCKS_PER_SEC on alpha. - Jeff Garzik: ramfs and highmem: kmap() the page to clear it - Asit Mallick: enable the APIC in the official order - Neil Brown: avoid rd deadlock on io_request_lock by using a private rd-request function. This also avoids unnecessary request merging at this level. - Ben LaHaise: vmalloc threadign and overflow fix - Randy Dunlap: USB updates (plusb driver). PCI cacheline size. - Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1 - Alan Cox: various (Athlon mmx copy, NULL ptr checks for scsi_register etc). - Al Viro: fix /proc permission check security hole. - Can-Ru Yeou: SiS301 fbcon driver - Andrew Morton: NMI oopser and kernel page fault punch through both console_lock and timerlist_lock to make sure it prints out.. - Jeff Garzik: clean up "kmap()" return type (it returns a kerne
[PATCH] bttv_card & bttv_radio (was Re: BTTV detection broken in 2.4.0-test11-pre5)
Gerd Knorr wrote:
> Why? What is the point in compiling bttv statically into the kernel?
Well, I see the modules vs. static flame war is already in progress ;-)
My reason for wanting static kernels is that I usually build many, very
different versions of the same kernel, among which I frequently switch
back and forth, and which I copy to different machines. Modules just get
in the way here.
I'm not at all against modules in general, quite to the contrary, but
there are cases where a static kernel is preferrable, and since it's
easy to keep the driver usable also without modules, I think it's worth
the effort.
Since we don't have Keith Owens' wonderful extension yet, I've made a
patch for 2.4.0-test11-pre7 that adds the new option bttv_card, and
renames bt848_radio to bttv_radio, replacing my previous patch. It also
fixes a rather embarrassing mistake I made in the bt848_radio patch ...
- Werner
-- cut here ---
--- linux.orig/Documentation/kernel-parameters.txt Tue Sep 5 22:51:14 2000
+++ linux/Documentation/kernel-parameters.txt Mon Nov 20 02:15:59 2000
@@ -43,6 +43,7 @@
SERIAL Serial support is enabled.
SMP The kernel is an SMP kernel.
SOUND Appropriate sound system support is enabled.
+ V4L Video For Linux support is enabled.
VGA The VGA console has been enabled.
VT Virtual terminal support is enabled.
XT IBM PC/XT MFM hard disk support is enabled.
@@ -115,6 +116,20 @@
Duplex Mode.
bmouse= [HW,MOUSE,PS2] Bus mouse.
+
+ bttv_card= [HW,V4L] Specify the model of the BT848/878 card(s),
+ superseding any auto-detection. The values are
+ described in Documentation/video4linux/bttv/CARDLIST.
+ E.g. bttv_card=2 specifies "Hauppauge old" for the
+ first card, bttv_card=3,3 specifies "STB" for the
+ first two cards.
+
+ bttv_radio= [HW,V4L] Enables the FM radio tuners of BT848/878
+ cards. This parameter corresponds to the radio= module
+ parameter if the driver is compiled as such, e.g.
+ bttv_radio=1 enables the radio of the first card,
+ bttv_radio=0,1 enables the radio of the second card,
+ etc.
BusLogic= [HW,SCSI]
--- linux.orig/drivers/media/video/bttv-cards.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/media/video/bttv-cards.c Mon Nov 20 03:07:22 2000
@@ -1319,6 +1319,24 @@
}
}
+#ifndef MODULE
+
+static int __init bttv_card_setup(char *str)
+{
+ int i,number,res = 2;
+
+ for (i = 0; res == 2 && i < BTTV_MAX; i++) {
+ res = get_option(&str,&number);
+ if (res)
+ card[i] = number;
+ }
+ return 1;
+}
+
+__setup("bttv_card=", bttv_card_setup);
+
+#endif /* not MODULE */
+
/*
* Local variables:
* c-basic-offset: 8
--- linux.orig/drivers/media/video/bttv-driver.cMon Nov 20 02:07:47 2000
+++ linux/drivers/media/video/bttv-driver.c Mon Nov 20 02:59:10 2000
@@ -3100,6 +3100,24 @@
module_init(bttv_init_module);
module_exit(bttv_cleanup_module);
+#ifndef MODULE
+
+static int __init bttv_radio_setup(char *str)
+{
+ int i,number,res = 2;
+
+ for (i = 0; res == 2 && i < BTTV_MAX; i++) {
+ res = get_option(&str,&number);
+ if (res)
+ radio[i] = number;
+ }
+ return 1;
+}
+
+__setup("bttv_radio=", bttv_radio_setup);
+
+#endif /* not MODULE */
+
/*
* Local variables:
* c-basic-offset: 8
--
_
/ Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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: Value of TASK_UNMAPPED_SIZE on 2.4
On Fri, Nov 03, 2000 at 02:36:22PM -0800, Josue Emmanuel Amaro wrote: > Andrea, > > We will give it a try. > > How difficult would it be to move that patch to 2.4? I moved it to 2.4.0-test11-pre5 (should work with pre7 too): ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test11-pre5/per-process-3.5G-IA32-no-PAE-1 It won't work with PAE enabled though (64G option). Making it to work with PAE enabled isn't much more complicated and I'll address that later (but in the meantime you can use it on <= 4GB RAM machines). Andrea - 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/
PROBLEM: tmscsim driver on test11-pre7 stops working when starting X
Hi, my Dawicontrol 2974 SCSI-adapter fails with kernel 2.4.0-test10 with pre-11 and reiserfs for kernel test-10 patched in: -- Nov 20 01:30:23 wh36-b407 kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Read (10) 00 00 08 c0 6c 00 00 f8 00 Nov 20 01:30:23 wh36-b407 kernel: DC390: Abort command (pid 0, DCB c12c11c0, SRB ) Nov 20 01:30:23 wh36-b407 kernel: DC390: Status of last IRQ (DMA/SC/Int/IRQ): 0890cc20 Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: SCSI block: Nov 20 01:30:23 wh36-b407 kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS Ctl1 Ctl2 Ctl3 Ctl4 Nov 20 01:30:23 wh36-b407 kernel: DC390: 00 44 10 cc 00 80 17 48 18 04 Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: DMA engine: Nov 20 01:30:23 wh36-b407 kernel: DC390: Cmd STrCntSBusAWrkBCWrkAC Stat SBusCtrl Nov 20 01:30:23 wh36-b407 kernel: DC390: 80 1000 051a4000 051a5000 00 0308 Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: PCI Status: 0200 Nov 20 01:30:23 wh36-b407 kernel: DC390: In case of driver trouble read linux/drivers/scsi/README.tmscsim Nov 20 01:30:23 wh36-b407 kernel: DC390: Aborted pid 0 with status 0 Nov 20 01:30:23 wh36-b407 kernel: SCSI host 0 abort (pid 0) timed out - resetting Nov 20 01:30:23 wh36-b407 kernel: SCSI bus is being reset for host 0 channel 0. Nov 20 01:30:23 wh36-b407 kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 2504 Nov 20 01:30:23 wh36-b407 kernel: I/O error: dev 08:02, sector 448928 Nov 20 01:30:27 wh36-b407 kernel: SysRq: Emergency Sync Nov 20 01:30:27 wh36-b407 kernel: Syncing device 03:08 ... OK Nov 20 01:30:27 wh36-b407 kernel: Syncing device 03:01 ... OK Nov 20 01:30:29 wh36-b407 kernel: Syncing device 09:00 ... OK Nov 20 01:30:29 wh36-b407 kernel: Done. Nov 20 01:31:46 wh36-b407 kernel: Kernel logging (proc) stopped. Nov 20 01:31:46 wh36-b407 kernel: Kernel log daemon terminating. Nov 20 01:31:46 wh36-b407 exiting on signal 15 -- This happened on the second bootup with the new kernel, when kdm was starting Xfree 4.0.1 from Debian woody. the tmscsim driver is initialized with: -- Nov 20 01:29:34 wh36-b407 kernel: SCSI subsystem driver Revision: 1.00 Nov 20 01:29:34 wh36-b407 kernel: DC390_init: No EEPROM found! Nov 20 01:29:34 wh36-b407 kernel: DC390_init: Trying default EEPROM settings: Nov 20 01:29:34 wh36-b407 kernel: DC390: Used defaults: AdaptID=7, SpeedIdx=1 (8.0 MHz), DevMode=0x1f, AdaptMode=0x0f, TaggedCmnds=3 (16) Nov 20 01:29:34 wh36-b407 kernel: Bad boy: tmscsim (at 0xc02bf732) called us without a dev_id! Nov 20 01:29:34 wh36-b407 kernel: DC390: 1 adapters found Nov 20 01:29:34 wh36-b407 kernel: scsi0 : Tekram DC390/AM53C974 V2.0d 1998/12/25 Nov 20 01:29:34 wh36-b407 kernel: DC390: Target 0: Sync transfer 8.0 MHz, Offset 15 Nov 20 01:29:34 wh36-b407 kernel: Vendor: IBM Model: DCAS-34330Rev: S61A Nov 20 01:29:34 wh36-b407 kernel: Type: Direct-Access ANSI SCSI revision: 02 Nov 20 01:29:34 wh36-b407 kernel: DC390: Target 5: Sync transfer 8.0 MHz, Offset 15 Nov 20 01:29:34 wh36-b407 kernel: Vendor: RICOH Model: MP6200S Rev: 2.40 Nov 20 01:29:34 wh36-b407 kernel: Type: CD-ROM ANSI SCSI revision: 02 Nov 20 01:29:34 wh36-b407 kernel: Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Nov 20 01:29:34 wh36-b407 kernel: SCSI device sda: 8467200 512-byte hdwr sectors (4335 MB) Nov 20 01:29:34 wh36-b407 kernel: sda: sda1 sda2 sda3 sda4 Nov 20 01:29:34 wh36-b407 kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 5, lun 0 Nov 20 01:29:34 wh36-b407 kernel: sr0: scsi3-mmc drive: 6x/6x writer cd/rw xa/form2 cdda tray Nov 20 01:29:34 wh36-b407 kernel: Uniform CD-ROM driver Revision: 3.11 -- I noted there's a new version of the driver on the maintainer's (Kurt Garloff) homepage, but last time I tested it and reported an oops with 2.4.test-something he didn't reply at all (that's not an offense, it's understandable with the amount of work he's doing for KDE2 etc). So should I a) try with his patch again; my oops report for that is attached below b) wait you can make of this bugreport c) provide any further info/testing? BTW, 2.2.17 with the stock tmscsim works fine everytime; with that kernel (and no other changes) the system is excessively stable :) CU, Yours Malte #8-) PS: Please cc me, I'm usually watching the lists I report bugs to, but LKML is a bit... excessive; I'll monitor the list from time to time, but can't guarantee timely responses... System specs: AMD K6-2 333 on a TX430-based Mainboard, not overclocked; additional cards are: ISA - CL Soundblaster 16 PnP ISA - NE2k-clone PCI - Dawicontrol 2974 Fast-SCSI, based on AMD53... chip - ATI Rage Pro LT PCI 8 MB - Hauppauge WinTV Theatre (bttv878) now the bug report with Garloff's new driver (I was using a scanner in addition, but the ker
Re: lseek/llseek allows the negative offset
On Sat, Nov 18, 2000 at 05:20:34PM -0800, H . J . Lu wrote:
> --- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000
> +++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
> @@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
> {
> switch (orig) {
> case 0:
> - file->f_pos = offset;
> - return file->f_pos;
> + break;
> case 1:
> - file->f_pos += offset;
> - return file->f_pos;
> + offset += file->f_pos;
> + break;
> default:
> return -EINVAL;
> }
> + if (offset < 0)
> + return -EINVAL;
> + file->f_pos = offset;
> + return offset;
> }
This looks fine to me.
Andrea
-
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: "No IRQ known for interrupt pin A..." error message
Gerhard Mack <[EMAIL PROTECTED]> writes:
> That looks exactly like the message I get if I tell the bios not to
> assign an interrupt to my video card.
>
unfortunately, i don't get such a choice. and if what you say is true,
isn't the message ("No IRQ known for interrupt pin A of device
05:00.0. Please try using pci=biosirq") misleading? to me this means
the kernel couldn't find the irq by itself, so it will ask the bios.
but if the irq is not assigned in the bios, how can kernel find it
then? maybe i should look at the code itself to try to understand what
is going on here (chances are i won't understand the code anyway, so
that's why i'm asking).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
-
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.4.0-test11-pre7: isapnp hang
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > Try reserving ports 0x300-0x31f on the kernel command line
> > ("reserve=0x300,0x20").
> >
> > I'm surprised isapnp uses a port in such a commonly used range,
> > though.
>
> It seems to be a combination of two bugs. The one I posted a patch for and
> something odd that is taking port 0x279 before the pnp probe is run, which
> suggests a link order issue. Although in truth _nobody_ should be claing
> that anyway
>
It seems to me that it would be better to initialize all the (non-PnP)
ISA cards first, and have them claim their preferred ranges. Now you
can pick the PnP isolate port out of what is left, and also have a
much better idea of what is available.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: BTTV detection broken in 2.4.0-test11-pre5
On Sun, 19 Nov 2000, Dan Hollis wrote: > Writeprotect the flashbios with the motherboard jumper, and remove the > cmos battery. > > Checkmate. :-) Only if you run your kernel XIP from the flash. If you load it into RAM, it's still possible for an attacker to modify it. You can load new code into the kernel even if the kernel doesn't make it easy for you by having CONFIG_MODULES defined. -- dwmw2 - 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.4 sendfile() not doing as manpage promises?
On Sun, 19 Nov 2000, Andries Brouwer wrote: > Moreover, the text Dan Hollis quotes is rather strange It's from redhat 6.0 man-pages-1.23-3 rpm package. -Dan - 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.4.0-test11-pre7: isapnp hang
> Try reserving ports 0x300-0x31f on the kernel command line
> ("reserve=0x300,0x20").
>
> I'm surprised isapnp uses a port in such a commonly used range,
> though.
It seems to be a combination of two bugs. The one I posted a patch for and
something odd that is taking port 0x279 before the pnp probe is run, which
suggests a link order issue. Although in truth _nobody_ should be claing
that anyway
-
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: What is 2.4.0-test10: md1 has overlapping physical units with md2!
Linus, Ingo:
the attached patch, modifies a warning message in md.c which seems to
often cause confusion - the following email includes one example
there-of (there have been others over the months).
Hopefully the new text is clearer.
(patch against 2.4.0-test11-pre7)
NeilBrown
On Sunday November 19, [EMAIL PROTECTED] wrote:
> On Sun, Nov 19, 2000 at 03:39:43AM -0800, George Garvey wrote:
> > Is this something to be concerned about? It sounds like a disaster waiting
> > to happen from the message. This is on 2 systems (with similar disk setups
> > [same other than size]).
>
> > Nov 18 16:31:02 mwg kernel: md: serializing resync, md1 has overlapping physical
>units with md2!
>
> Nope, nothing to worry about -- it's just a bad choice of wording ;)
>
> What it means is that some partititions in md1 and md2 are on the same disk,
> and that the md-code will not do the reconstruction of these arrays in
> parallel [of course, for performance reasons].
>
--- ./drivers/md/md.c 2000/11/20 00:33:08 1.2
+++ ./drivers/md/md.c 2000/11/20 00:44:19 1.3
@@ -3279,7 +3279,7 @@
if (mddev2 == mddev)
continue;
if (mddev2->curr_resync && match_mddev_units(mddev,mddev2)) {
- printk(KERN_INFO "md: serializing resync, md%d has overlapping
physical units with md%d!\n", mdidx(mddev), mdidx(mddev2));
+ printk(KERN_INFO "md: serializing resync, md%d has shares one
+or more physical units with md%d!\n", mdidx(mddev), mdidx(mddev2));
serialize = 1;
break;
}
-
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.4.0-test11-pre7: isapnp hang
Followup to: <[EMAIL PROTECTED]>
By author:Tim Waugh <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Reading from port 0x313 (my ISA NE2000 is at 0x300-0x31f) hangs my
> machine dead. Unfortunately, reading from that port is exactly what
> the isapnp code does on boot, if compiled into the kernel.
>
> Is it the network card's fault (probably), or is there a less invasive
> probe that isapnp could use (unlikely, I guess)?
>
Try reserving ports 0x300-0x31f on the kernel command line
("reserve=0x300,0x20").
I'm surprised isapnp uses a port in such a commonly used range,
though.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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.4.0-test11-pre7: isapnp hang
> > Is it the network card's fault (probably), or is there a less invasive
> > probe that isapnp could use (unlikely, I guess)?
>
>
> That shouldnt be possible - we are supposed to start at 0x203 and skip the
> problem area.
And a quick read of the code I pasted instead of just pasting suggests instead
we should be using the patch below. Question however is who stole port 0x279
which is the normal port to use. It shouldnt be lp since lp is supposed to
init after pnp.
--- drivers/pnp/isapnp.c.oldTue Oct 31 20:29:59 2000
+++ drivers/pnp/isapnp.cSun Nov 19 23:43:15 2000
@@ -270,17 +270,16 @@
{
int rdp = isapnp_rdp;
while (rdp <= 0x3ff) {
- if (!check_region(rdp, 1)) {
- isapnp_rdp = rdp;
- return 0;
- }
- rdp += RDP_STEP;
/*
* We cannot use NE2000 probe spaces for ISAPnP or we
* will lock up machines.
*/
- if(rdp >= 0x280 && rdp <= 0x380)
- continue;
+ if ((rdp < 0x280 || rdp > 0x380) && !check_region(rdp, 1))
+ {
+ isapnp_rdp = rdp;
+ return 0;
+ }
+ rdp += RDP_STEP;
}
return -1;
}
-
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] Large "clipped" IDE disk support for 2.4 when using oldBIOS
On Sun, 19 Nov 2000, Andre Hedrick wrote: > On Mon, 20 Nov 2000, Dan Aloni wrote: > > > Well, I could patch it so it adds that one sector ;-) But that's not the > > right way. The true number of sectors is 90069840, since 90069839 doesn't > > divide by the number of *real* heads (6) and the number of recording zones > > (15). So it needs fixing. > > 15 == 16 if 0 == 1 in realm of counting numbers. > > Also geometry is a lie to begin with, so what is one more lie on top of > another? These are real values, IBM: http://www.storage.ibm.com/hardsoft/diskdrdl/desk/ds75gxp.htm Let's try to read from the 90069840th sector: # dd if=/dev/hdc of=/dev/null bs=512 count=1 skip=90069839 1+0 records in 1+0 records out Walla. ;-) -- Dan Aloni [EMAIL PROTECTED] - 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: "No IRQ known for interrupt pin A..." error message
That looks exactly like the message I get if I tell the bios not to assign an interrupt to my video card. Gerhard On 19 Nov 2000, Alex Romosan wrote: > Martin Mares <[EMAIL PROTECTED]> writes: > > > > During boot, I get the message: > > > > > > PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try > > > using pci=biosirq. > > > > Can you send me 'lspci -vvx' output, please? > > > > i am not the original poster, but i get the same message (save for the > device number), i.e. "PCI: No IRQ known for interrupt pin A of device > 05:00.0. Please try using pci=biosirq". this is on a dell latitude > running 2.4.0-test11-pre7. the output from 'lspci -vvx' follows: > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP >disabled) (rev 02) > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR+ FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-Latency: 32 > Region 0: Memory at d000 (32-bit, prefetchable) [size=256M] > 00: 86 80 92 71 06 01 00 a2 02 00 00 06 00 20 00 00 > 10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00:02.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] >(rev 01) (prog-if 00 [VGA]) > Subsystem: Dell Computer Corporation MagicGraph 128XD > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-Interrupt: pin A routed to IRQ 11 > Region 0: Memory at e000 (32-bit, prefetchable) [size=16M] > Region 1: Memory at fde0 (32-bit, non-prefetchable) [size=2M] > Region 2: Memory at fdd0 (32-bit, non-prefetchable) [size=1M] > 00: c8 10 04 00 03 00 80 02 01 00 00 03 00 20 00 00 > 10: 08 00 00 e0 00 00 e0 fd 00 00 d0 fd 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 74 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 10 ff > > 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) > Subsystem: Dell Computer Corporation: Unknown device 0074 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-Latency: 168, cache line size 08 > Interrupt: pin A routed to IRQ 11 > Region 0: Memory at 1000 (32-bit, non-prefetchable) [size=4K] > Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 > Memory window 0: 1040-107ff000 (prefetchable) > Memory window 1: 1080-10bff000 > I/O window 0: 1000-10ff > I/O window 1: 1400-14ff > BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+ > 16-bit legacy interface ports at 0001 > 00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 a8 82 00 > 10: 00 00 00 10 00 00 00 02 00 01 01 b0 00 00 40 10 > 20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 10 00 00 > 30: fc 10 00 00 00 14 00 00 fc 14 00 00 0b 01 c0 05 > 40: 28 10 74 00 01 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) > Subsystem: Dell Computer Corporation: Unknown device 0074 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-Latency: 168, cache line size 08 > Interrupt: pin B routed to IRQ 11 > Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K] > Bus: primary=00, secondary=05, subordinate=05, sec-latency=176 > Memory window 0: 10c0-10fff000 (prefetchable) > Memory window 1: 1100-113ff000 > I/O window 0: 1800-18ff > I/O window 1: 1c00-1cff > BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+ > 16-bit legacy interface ports at 0001 > 00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 a8 82 00 > 10: 00 10 00 10 00 00 00 02 00 05 05 b0 00 00 c0 10 > 20: 00 f0 ff 10 00 00 00 11 00 f0 3f 11 00 18 00 00 > 30: fc 18 00 00 00 1c 00 00 fc 1c 00 00 0b 02 00 05 > 40: 28 10 74 00 01 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- >SERR+ FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-Latency: 0 > 00: 86 80 10 71 0f 01 80 02 01 00 80 06 00 00 80
Re: 2.4.0-test11-pre7: isapnp hang
> Reading from port 0x313 (my ISA NE2000 is at 0x300-0x31f) hangs my
> machine dead. Unfortunately, reading from that port is exactly what
> the isapnp code does on boot, if compiled into the kernel.
>
> Is it the network card's fault (probably), or is there a less invasive
> probe that isapnp could use (unlikely, I guess)?
That shouldnt be possible - we are supposed to start at 0x203 and skip the
problem area.
static int isapnp_next_rdp(void)
{
int rdp = isapnp_rdp;
while (rdp <= 0x3ff) {
if (!check_region(rdp, 1)) {
isapnp_rdp = rdp;
return 0;
}
rdp += RDP_STEP;
/*
* We cannot use NE2000 probe spaces for ISAPnP or we
* will lock up machines.
*/
if(rdp >= 0x280 && rdp <= 0x380)
continue;
}
return -1;
}
If you can find out why that port is being touched I'd like to know
-
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/
Compile bugfix for ramfs limits
Oops.. not . The patch below
implements resource limits for ramfs, and unlike the previous version
actually compiles.
--
David Gibson, Technical Support Engineer, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
diff -uNr test11-pre5/Documentation/filesystems/ramfs.txt
test11-pre5-ramfs/Documentation/filesystems/ramfs.txt
--- test11-pre5/Documentation/filesystems/ramfs.txt Thu Jan 1 10:00:00 1970
+++ test11-pre5-ramfs/Documentation/filesystems/ramfs.txt Wed Nov 15 14:12:08
+2000
@@ -0,0 +1,47 @@
+ ramfs - An automatically resizing memory based filesystem
+
+
+ Ramfs is a file system which keeps all files in RAM. It allows read
+ and write access. In contrast to RAM disks, which get allocated a
+ fixed amount of RAM, ramfs grows and shrinks to accommodate the
+ files it contains.
+
+ You can mount the ramfs with:
+ mount -t ramfs none /mnt/wherever
+
+ Then just create and use files. When the filesystem is unmounted, all
+ its contents are lost.
+
+ NOTE! This filesystem is probably most useful not as a real
+ filesystem, but as an example of how virtual filesystems can be
+ written.
+
+Resource limits:
+
+By default a ramfs will be limited to using half of (physical) memory
+for storing file contents, a bit over that when the metadata is
+included. The resource usage limits of ramfs can be controlled with
+the following mount options:
+
+ maxsize=NNN
+ Sets the maximum allowed memory usage of the
+filesystem to NNN kilobytes. This will be rounded down to a multiple
+of the page size. The default is half of physical memory. NB. unlike
+most of the other limits, setting this to zero does *not* mean no
+limit, but will actually limit the size of the filesystem data to zero
+pages. There might be a use for this in some perverse situation.
+
+ maxfilesize=NNN
+ Sets the maximum size of a single file on the
+filesystem to NNN kilobytes. This will be rounded down to a multiple
+of the page size. If NNN=0 there is no limit. The default is no limit.
+
+ maxdentries=NNN
+ Sets the maximum number of directory entries (hard
+links) on the filesystem to NNN. If NNN=0 there is no limit. By
+default this is set to maxsize/4.
+
+ maxinodes=NNN
+ Sets the maximum number of inodes (i.e. distinct
+files) on the filesystem to NNN. If NNN=0 there is no limit. The
+default is no limit (but there can never be more inodes than dentries).
diff -uNr test11-pre5/fs/ramfs/inode.c test11-pre5-ramfs/fs/ramfs/inode.c
--- test11-pre5/fs/ramfs/inode.cWed Nov 15 14:06:48 2000
+++ test11-pre5-ramfs/fs/ramfs/inode.c Mon Nov 20 10:50:24 2000
@@ -4,6 +4,7 @@
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
*
+ * Usage limits added by David Gibson, Linuxcare Australia.
* This file is released under the GPL.
*/
@@ -28,8 +29,18 @@
#include
#include
#include
+#include
+#include
#include
+#include
+
+#if PAGE_CACHE_SIZE % 1024
+#error Oh no, PAGE_CACHE_SIZE is not divisible by 1k! I cannot cope.
+#endif
+
+#define IBLOCKS_PER_PAGE (PAGE_CACHE_SIZE / 512)
+#define K_PER_PAGE (PAGE_CACHE_SIZE / 1024)
/* some random number */
#define RAMFS_MAGIC0x858458f6
@@ -40,8 +51,174 @@
static struct file_operations ramfs_file_operations;
static struct inode_operations ramfs_dir_inode_operations;
+/*
+ * ramfs super-block data in memory
+ */
+struct ramfs_sb_info {
+ /* Prevent races accessing the used block
+* counts. Conceptually, this could probably be a semaphore,
+* but the only thing we do while holding the lock is
+* arithmetic, so there's no point */
+ spinlock_t ramfs_lock;
+
+ /* It is important that at least the free counts below be
+ signed. free_XXX may become negative if a limit is changed
+ downwards (with a remount) below the current usage. */
+
+ /* maximum number of pages in a file */
+ long max_file_pages;
+
+ /* max total number of data pages */
+ long max_pages;
+ /* free_pages = max_pages - total number of pages currently in use */
+ long free_pages;
+
+ /* max number of inodes */
+ long max_inodes;
+ /* free_inodes = max_inodes - total number of inodes currently in use */
+ long free_inodes;
+
+ /* max number of dentries */
+ long max_dentries;
+ /* free_dentries = max_dentries - total number of dentries in use */
+ long free_dentries;
+};
+
+#define RAMFS_SB(sb) ((struct ramfs_sb_info *)((sb)->u.generic_sbp))
+
+/*
+ * Resource limit helper functions
+ */
+
+static inline void lock_rsb(struct ramfs_sb_info *rsb)
+{
+ spin_lock(&(rsb->ramfs_lock));
+}
+
+static inline void unlock_rsb(struct ramfs_sb_info *rsb)
+{
+ spin_unlock(&(rsb->ramfs_lock));
+}
+
+/* Decrements the free inode count and returns true, or
Re: [PATCH] Large "clipped" IDE disk support for 2.4 when using oldBIOS
On Mon, 20 Nov 2000, Dan Aloni wrote: > Well, I could patch it so it adds that one sector ;-) But that's not the > right way. The true number of sectors is 90069840, since 90069839 doesn't > divide by the number of *real* heads (6) and the number of recording zones > (15). So it needs fixing. 15 == 16 if 0 == 1 in realm of counting numbers. Also geometry is a lie to begin with, so what is one more lie on top of another? Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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] Large "clipped" IDE disk support for 2.4 when using oldBIOS
On Mon, 20 Nov 2000, Taisuke Yamada wrote: > > > > > This patch is not good...[snip] > > > > > > Please retest with hdc=... > > > > Ok, I've booted without the parameter, and without the jumper on > > clipping mode (I'll do it tommorow, it's 1AM now) got something > > similiar to what you've written, and everything looks ok. > > Great, so it worked. > > # Since it worked, please discard my message I sent you to wait. > > > Now it reports 90069839 - one sector less. Any damage risk to > > my filesystems? > > Hmm, that will be trouble if you access that last sector. I'll > take a look at it after I came back from my work (It's 8AM now > and got to go to work :-). Well, I could patch it so it adds that one sector ;-) But that's not the right way. The true number of sectors is 90069840, since 90069839 doesn't divide by the number of *real* heads (6) and the number of recording zones (15). So it needs fixing. -- Dan Aloni [EMAIL PROTECTED] - 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: ATA/IDE: dmaproc error 14 testers wanted!
/pub/linux/kernel/people/hedrick/ide-2.2.17/README /pub/linux/kernel/people/hedrick/ide-2.2.17/ide.2.2.17.all.20001118.patch.bz2 There you go Sean, hope that helps. Cheers, On Sun, 19 Nov 2000, Sean B. Estabrooks wrote: > > > It is on kernel.org and the README tells you what to do to enable the stub > > in ide-dma.c If it works let me know! > > Andre, > > Where on kernel.org are you hiding the README and patch files you > mention? > >Regards, > Sean > > - > 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/ > Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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.4.0-test11-pre7: isapnp hang
Reading from port 0x313 (my ISA NE2000 is at 0x300-0x31f) hangs my machine dead. Unfortunately, reading from that port is exactly what the isapnp code does on boot, if compiled into the kernel. Is it the network card's fault (probably), or is there a less invasive probe that isapnp could use (unlikely, I guess)? Tim. */ PGP signature
Loud screech after reboot of 2.2.18-pre22
Hi,
I have a Sony VAIO Z505JE with ymfpci sound and built-in microphone
and speaker. Everything worked fine with 2.2.17 plus ymfpci patch,
but the 2.2.18-pre22 produces a loud screech starting as sound
initializes and ending when startup scrips load mixer settings.
This happens because of audio loop between microphone and speakers.
I found that the culprit is the change to values of array
mixer_defaults[] in ac97_codec.c, that happened in 2.2.18-pre.
Currently I run the following patch:
--- linux-2.2.18-pre22/drivers/sound/ac97_codec.c Sat Nov 18 19:04:34 2000
+++ linux-2.2.18-pre22-p3/drivers/sound/ac97_codec.cSun Nov 19 15:37:44 2000
@@ -131,7 +131,7 @@
{SOUND_MIXER_PCM, 0x4343},
{SOUND_MIXER_SPEAKER, 0x4343},
{SOUND_MIXER_LINE, 0x4343},
- {SOUND_MIXER_MIC, 0x4343},
+ {SOUND_MIXER_MIC, 0x},/* P3 - audio loop */
{SOUND_MIXER_CD,0x4343},
{SOUND_MIXER_ALTPCM,0x4343},
{SOUND_MIXER_IGAIN, 0x4343},
I wonder if there is a better way?
In the interests of full disclosure let me mention that YMFxxx do have
internal loopbacks that may produce the same effect and that I checked
to the best of my ability that those loopbacks are muted. Therefore
I conclude that the loopback happens inside the AC97 (if such a thing
is possible).
--Pete
-
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/
VFS busy inodes after umount -- have a nice day...
Hi, Here is how I manage to hit this under 2.4.0-test11-pre6 1. mkfs an ext2 filesystem on a 36G disk 2. do a complex combination of data and metadata io on it by means of SPECsfs with LOADs high enough to run out of space 3. observe that both high and low memory are almost zero, i.e. about 2M each (total is 6G) now try to umount the filesystem and you'll get the above. I will try test11-pre7 tomorrow... Regards, Tigran - 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/
USB Mass Storage and test11pre7
I have testing a HP 8200e USB CDRW Driver with this version of kernel. With the vainilla test10, after wrinting 14 MB, the cdrecotrd proccess lock, and I have the next messsage imn the logs: Nov 19 22:35:34 localhost kernel: usb_control/bulk_msg: timeout These doesn't happen with test10. But I only have success with the test10 with 1 cdrom. With Windows and Nero no problems burning cd ( I test for hardware problems). How I can help debug these issue. Saludos Drizzt -- ... No es oro todo lo que reluce, ni toda la gente errante anda perdida. Drizzt Do'UrdenThree rings for the Elves Kings under the Sky [EMAIL PROTECTED] Seven for the Dwarf_lords in their hall of stone Nine for the Mortal Men doomed to die - 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] Large "clipped" IDE disk support for 2.4 when using old BIOS
> > > This patch is not good...[snip] > > > > Please retest with hdc=... > > Ok, I've booted without the parameter, and without the jumper on > clipping mode (I'll do it tommorow, it's 1AM now) got something > similiar to what you've written, and everything looks ok. Great, so it worked. # Since it worked, please discard my message I sent you to wait. > Now it reports 90069839 - one sector less. Any damage risk to > my filesystems? Hmm, that will be trouble if you access that last sector. I'll take a look at it after I came back from my work (It's 8AM now and got to go to work :-). -- Taisuke Yamada <[EMAIL PROTECTED]> PGP fingerprint = 6B 57 1B ED 65 4C 7D AE 57 1B 49 A7 F7 C8 23 46 - 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] Remove tq_scheduler
On Sat, 18 Nov 2000, Andrew Morton wrote: > > This patch removes tq_scheduler from the kernel. All uses of > tq_scheduler are migrated over to use schedule_task(). > > Notes: > - If anyone sleeps in a callback, then all other users of > schedule_task() also sleep. But there's nothing new here. Kinda > makes one wonder why schedule_task exists. But what-hey, it's neat. Because you're only supposed to use it if the task that is scheduled: A) Doesn't care about a reasonable delay B) Doesn't sleep for an unreasonable amount of time. As long as there's some value of 'reasonable' to match the set of tasks which you are using schedule_task() for at any given moment, you should be fine. If it's really necessary in 2.5, we can consider using multiple queues to get round this problem - either a task per subsystem or a pool of worker threads. Hopefully it won't be necessary though. We'll see. > - Note the careful massaging of module reference counts. > > Yes my friends, much usage of task queues in modules is racy wrt > module removal. This patch fixes some of them. Cool. I was going to look into that. I had figured we should fix it completely or not at all, though, which is why I didn't do the trick with use counts. I probably should have done, though. While you're in maintenance mode, do you feel like fixing up stuff to use up_and_exit() for killing kernel threads? I started on net/sunrpc/sched.c but it made my head hurt so I gave up and started hacking PCMCIA instead :) Also, drivers/usb/hub.c can probably use schedule_task() now instead of its own kernel thread. -- dwmw2 - 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] Large "clipped" IDE disk support for 2.4 when usingoldBIOS
On Mon, 20 Nov 2000, Taisuke Yamada wrote: > > This patch is not good. It compiles, but when I boot the kernel, it > > decides to ignore the hdc=5606,255,63 parameter that I pass to the kernel, > > and limits the number of sectors to fill 8.4GB. > > Please retest with hdc=... parameter removed. If hd[a-z]=... > parameter is specified, my patch will be disabled, trusting > whatever user has specified. > Ok, I've booted without the parameter, and without the jumper on clipping mode (I'll do it tommorow, it's 1AM now) got something similiar to what you've written, and everything looks ok. BTW, I have created the paratition table and all paratitions when the drive reported 90069840 sectors. Now it reports 90069839 - one sector less. Any damage risk to my filesystems? dmesg: hdc: host protected area => 1 hdc: checking for max native LBA... hdc: max native LBA is 90069839 hdc: (un)clipping max LBA... hdc: max LBA (un)clipped to 90069839 hdc: lba = 1, cap = 90069839 hdc: 90069839 sectors (46116 MB) w/1916KiB Cache, CHS=89354/16/63, UDMA(33) Partition check: hdc: [PTBL] [5606/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 > > hda: host protected area => 1 > hda: checking for max native LBA... > hda: max native LBA is 90045647 > hda: (un)clipping max LBA... > hda: max LBA (un)clipped to 90045647 > hda: lba = 1, cap = 90045647 > hda: 90045647 sectors (46103 MB) w/2048KiB Cache, CHS=89330/16/63, UDMA(33) > hdc: host protected area => 1 > hdc: checking for max native LBA... > hdc: max native LBA is 90045647 > hdc: (un)clipping max LBA... > hdc: max LBA (un)clipped to 90045647 > hdc: lba = 1, cap = 90045647 > hdc: 90045647 sectors (46103 MB) w/2048KiB Cache, CHS=89330/16/63, UDMA(33) -- Dan Aloni [EMAIL PROTECTED] - 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/
run level 1, login takes too long, 2.4.X vs. 2.2.X
I had occasion to "telinit 1" today and found that it took a long time
to login after root passwd was entered. this doesn't happen with 2.2.X
kernels.
Is this to be expected with the 2.4 series kernels? or a bug?
Martin
strace for 2.4.0-test11-pre7
---snip---
gettimeofday({974665658, 952483}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 305
bind(3, {sin_family=AF_INET, sin_port=htons(905), sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffb33c) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffb344) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
---snip---
strace for 2.2.17
---snip---
gettimeofday({974664928, 735539}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 368
bind(3, {sin_family=AF_INET, sin_port=htons(968), sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "_c\353\331\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 5000) = 1
recvfrom(3, 0x8056380, 400, 0, 0xbfffd66c, 0xbfffd618) = -1 ECONNREFUSED (Connection
refused)
close(3)= 0
---snip---
-
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] Large "clipped" IDE disk support for 2.4 when using old BIOS
> > With this patch, you will be able to use disk capacity above > > 32GB (or 2GB/8GB depending on how clipping take effect), and > > still be able to boot off from the disk because you can leave > > the "clipping" turned on. > > I suppose you know that no kernel patch is required (since > setmax.c does the same from user space). Did you try setmax? I know of its existence, but thought patch solution is better than userland solution and made one. Unless it is included in the kernel, it's going to cause trouble on every system with old BIOS. After all, disk geometry detection is what the kernel should do, not userland program. > to me it seems a bit too early to come with kernel patches. But yes, you have the point here. This still needs more testing to see if it works with every 32GB+ drive. By the way, how did your drives behave? I have tested my code with IBM and Maxtor, and both supported this READ NATIVE MAX - SET MAX combination without any problem. > I think I already sent you setmax.c, but in case my memory > is confused let me include it here again. This is for 2.4. Actually, this is the first time to have setmax.c, but I have already made one myself to test my code. Your past discussion was pretty much informative :-). -- Taisuke Yamada <[EMAIL PROTECTED]> PGP fingerprint = 6B 57 1B ED 65 4C 7D AE 57 1B 49 A7 F7 C8 23 46 - 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: ATA/IDE: dmaproc error 14 testers wanted!
> It is on kernel.org and the README tells you what to do to enable the stub > in ide-dma.c If it works let me know! Andre, Where on kernel.org are you hiding the README and patch files you mention? Regards, Sean - 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.4 sendfile() not doing as manpage promises?
On Sun, Nov 19, 2000 at 05:36:23PM +0100, Andries Brouwer wrote: > DESCRIPTION >This call copies data between one file descriptor and >another. Either or both of these file descriptors may >refer to a socket. in_fd should be a file descriptor >opened for reading and out_fd should be a descriptor >opened for writing. > > If that is incorrect, then editing a private copy of the manpage, > as Dan Hollis, or the distributor from whom he got his page, > seems to have done, does not suffice to change the manpage distribution. Improved attempt: DESCRIPTION This call copies data between one file descriptor and another. The descriptor from which data is read cannot be a socket but must correspond to a file which supports mmap()-like operations. in_fd should be a filedescriptor opened for reading and out_fd should be a descriptor opened for writing. Because this copying is done within the kernel, sendfile() does not need to spend time transfering data to and from userspace. Regards, bert hubert -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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] Large "clipped" IDE disk support for 2.4 when using oldBIOS
> > Earlier this month, I had sent in a patch to 2.2.18pre17 (with > > IDE-patch from http://www.linux-ide.org/ applied) to add support > > for IDE disk larger than 32GB, even if the disk required "clipping" > > to reduce apparent disk size due to BIOS limitation. > > This patch is not good. It compiles, but when I boot the kernel, it > decides to ignore the hdc=5606,255,63 parameter that I pass to the kernel, > and limits the number of sectors to fill 8.4GB. Please retest with hdc=... parameter removed. If hd[a-z]=... parameter is specified, my patch will be disabled, trusting whatever user has specified. Here's a example output of what you should expect if the patched part is being executed: hda: host protected area => 1 hda: checking for max native LBA... hda: max native LBA is 90045647 hda: (un)clipping max LBA... hda: max LBA (un)clipped to 90045647 hda: lba = 1, cap = 90045647 hda: 90045647 sectors (46103 MB) w/2048KiB Cache, CHS=89330/16/63, UDMA(33) hdc: host protected area => 1 hdc: checking for max native LBA... hdc: max native LBA is 90045647 hdc: (un)clipping max LBA... hdc: max LBA (un)clipped to 90045647 hdc: lba = 1, cap = 90045647 hdc: 90045647 sectors (46103 MB) w/2048KiB Cache, CHS=89330/16/63, UDMA(33) > /* > * Compute drive->capacity, the full capacity of the drive > * Called with drive->id != NULL. > + * > + * To compute capacity, this uses either of > + * > + *1. CHS value set by user (whatever user sets will be trusted) > + *2. LBA value from target drive (require new ATA feature) > + *3. LBA value from system BIOS (new one is OK, old one may break) > + *4. CHS value from system BIOS (traditional style) > + * > + * in above order (i.e., if value of higher priority is available, > + * rest of the values are ignored). > */ -- Taisuke Yamada <[EMAIL PROTECTED]> PGP fingerprint = 6B 57 1B ED 65 4C 7D AE 57 1B 49 A7 F7 C8 23 46 - 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: "No IRQ known for interrupt pin A..." error message
> During boot, I get the message: > > PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try > using pci=biosirq. It is related to VGA card (at least on my system). Enabling 'Assign IRQ for VGA' in BIOS causes the message to disapear. Pavel - 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: rdtsc to mili secs?
On Sun, Nov 19, 2000 at 09:24:04PM +0100, Pavel Machek wrote: > Hi! > > > > > Anyway, this should be solvable by checking for clock change in the > > > > timer interrupt. This way we should be able to detect when the clock > > > > went weird with a 10 ms accuracy. And compensate for that. It should be > > > > possible to keep a 'reasonable' clock running even through the clock > > > > changes, where reasonable means constantly growing and as close to real > > > > time as 10 ms difference max. > > > > > > > > Yes, this is not perfect, but still keep every program quite happy and > > > > running. > > > > > > No. Udelay has just gone wrong and your old ISA xxx card just crashed > > > whole system. Oops. > > > > Yes. But can you do any better than that? Anyway, I wouldn't expect to > > be able to put my old ISA cards into a recent notebook which fiddles > > with the CPU speed (or STPCLK ratio). > > PCMCIA is just that: putting old ISA crap into modern hardware. Sorry. Not really, fortunately. There are ISA-sytle NE2000's on PCMCIA, but 1) You know that you have a card there via the PCMCIA services and 2) They're not the old crappy NE2000's that'd die on a random read anyway. -- Vojtech Pavlik SuSE Labs - 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: BTTV detection broken in 2.4.0-test11-pre5
On Sun, 19 Nov 2000 20:03:52 +0100 (CET), Gerd Knorr <[EMAIL PROTECTED]> wrote: >On Mon, 20 Nov 2000, Keith Owens wrote: >> On my list for 2.5. If foo is declared as MODULE_PARM in object bar >> then you will be able to boot with bar.foo=27 or even foo=27 as long as >> variable foo is unique amongst all objects in the kernel. > >Cool. Any plans how to handle drivers which are build from multiple >object files like bttv? Think "bar" needs to be configurable handle this >nicely. bttv should have bttv.card=xxx because the module is called >"bttv", but the source file where the card insmod option is declared is >bttv-cards.c ... The prefix will come from the module name, not the source name, even when the code is built into the kernel. So in the case of bttv it will be bttv.foo, not bttv-cards.foo. That needs information from the Makefile which is currently discarded, the Makefile processing for multi object modules needs to be changed, which is why it is a 2.5 change. - 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.4.0-test11-pre6 Destroyed vfat filesystem
Hello, After I mounted my windows partition under 2.4.0-test11pre6 the file system was corrupted. John - 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] megaraid driver update for 2.4.0-test10
> "dalecki" == dalecki <[EMAIL PROTECTED]> writes: A few questions after scanning through your patch, it's likely I missed something but I am kind acurious. dalecki> The attached patch does the following: 1. Merge the most dalecki> current version (aka: 1.08) of the MegaRAID driver from AMI dalecki> in to the most current kernel (2.4.0-test10 and friends). Hmmm I don't get it why you changed the return type of the readl/writel macros to return unsigned long rather than u32 - is there a reason for this other than to get sign extension? dalecki> 3. Fix the virt_to_phys mapping for scatter-gather transfers dalecki> as well as some other minor tidups here and there. What are you trying to achieve there? You run virt_to_phys() on a user space address as far as I can read and stick it into something labelled xferaddr? Normally you should never need the physical address in a device driver unless you want to play with page table settings or the like. If the address is to be handed to a DMA engine you should never take the physical address, but rather use virt_to_bus() or even better use the new 2.3+ PCI DMA API (pci_map_single()). Jes - 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/
VFAT corrupt files :?
I'm using 2.4.0-test11pre7 I calcute md5sum of some files in a ext2 partition. I move those files to a vfat partition. I duplicate the directory im the vfat partition. The duplicate set doesn't pass the md5sum. I have done various test and I can replicate they don't pass the md5 sum. Are there some problem with the vfat code :?. Some problem with my hardware :?. I have no overclocked hardware nor using dma on disks ( only multicount). Saludos Drizzt -- ... 10 IF "LAS RANAS"="TIENEN PELO" THEN PRINT "Windows is good". Drizzt Do'UrdenThree rings for the Elves Kings under the Sky [EMAIL PROTECTED] Seven for the Dwarf_lords in their hall of stone Nine for the Mortal Men doomed to die - 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: "No IRQ known for interrupt pin A..." error message
On Sun, Nov 19, 2000 at 08:20:33PM +0100, Martin Mares wrote: > > During boot, I get the message: > > > > PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try > > using pci=biosirq. > > Can you send me 'lspci -vvx' output, please? > Here you go: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00: 39 10 01 00 07 00 00 00 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 c0 c0 00 00 20: e0 eb e0 eb c0 fe c0 ff 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00:0b.0 Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 10) Subsystem: Unknown device 0291:8212 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Re: BTTV detection broken in 2.4.0-test11-pre5
Alexander Viro wrote: > On Sun, 19 Nov 2000, Christer Weinigel wrote: > > > In article <[EMAIL PROTECTED]> you write: > > >On Sun, 19 Nov 2000, Alexander Viro wrote: > > >> On Sun, 19 Nov 2000, David Lang wrote: > > >> > there is a rootkit kernel module out there that, if loaded onto your > > >> > system, can make it almost impossible to detect that your system has been > > >> > compramised. with module support disabled this isn't possible. > > >> Yes, it is. Easily. If you've got root you can modify the kernel image and > > >> reboot the bloody thing. And no, marking it immutable will not help. Open > > >> the raw device and modify relevant blocks. > > > > > >Kernel on writeprotected floppy disk... > > Cute. And when (not if) we get hit by new bug in the net/*/* you will drive > to the location of said router to upgrade the thing. > No, I mail the customer a new operating CD. -b > > > So change the CMOS-settings so that the BIOS changes the boot order > > from A, C, CD-ROM to C first instead. *grin* How long do you want > > to keep playing Tic-Tac-Toe? > > Now, _that_ can be taken care of (custom boot code burnt into the thing) > > > Of course, using capabilities and totally disabling access to the raw > > disk devices and to any I/O ports might be the solution, provided that > > there are no bugs or thinkos in the capabilities code. > > - > 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/ - 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: BTTV detection broken in 2.4.0-test11-pre5
Christer Weinigel wrote: > In article <[EMAIL PROTECTED]> you write: > >On Sun, 19 Nov 2000, Alexander Viro wrote: > >> On Sun, 19 Nov 2000, David Lang wrote: > >> > there is a rootkit kernel module out there that, if loaded onto your > >> > system, can make it almost impossible to detect that your system has been > >> > compramised. with module support disabled this isn't possible. > >> Yes, it is. Easily. If you've got root you can modify the kernel image and > >> reboot the bloody thing. And no, marking it immutable will not help. Open > >> the raw device and modify relevant blocks. > > > >Kernel on writeprotected floppy disk... > > So change the CMOS-settings so that the BIOS changes the boot order > from A, C, CD-ROM to C first instead. *grin* How long do you want > to keep playing Tic-Tac-Toe? > The way we do it is to boot from a CDROM with no onboard hard drive. (logging is provided by an external server) Beat that. -b > > Of course, using capabilities and totally disabling access to the raw > disk devices and to any I/O ports might be the solution, provided that > there are no bugs or thinkos in the capabilities code. > >/Christer > -- > "Just how much can I get away with and still go to heaven?" > - > 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/ - 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] dmfe.c transmission performance patch
[Please help me test this patch (for linux-2.4.0-test10/11)!]
This is my tx performance patch for dmfe, excluding the locking fixes,
which will appear in a separate patch. I would like feedback from testing
and code inspection. New since the last patch is the line printed when a
new card is found. (device name, MAC address, IO, IRQ)
Possible future work:
* Zero-copy transmission
* Use "new" PCI support API
/Tobias
--- dmfe.c.orig Sun Nov 19 21:43:33 2000
+++ dmfe.c Sun Nov 19 21:44:57 2000
@@ -57,6 +57,10 @@
Resource usage cleanups.
Report driver version to user.
+ Tobias Ringström <[EMAIL PROTECTED]> :
+ Rewrote the transmit code to actually use the ring buffer,
+ and to generate a lot fewer interrupts.
+
TODO
Implement pci_driver::suspend() and pci_driver::resume()
@@ -68,7 +72,7 @@
*/
-#define DMFE_VERSION "1.30 (June 11, 2000)"
+#define DMFE_VERSION "1.30p1 (November 15, 2000)"
#include
@@ -108,6 +112,7 @@
#define TX_MAX_SEND_CNT 0x1/* Maximum tx packet per time */
#define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
#define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
+#define TX_IRQ_THR 12
#define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
#define TX_BUF_ALLOC0x600
#define RX_ALLOC_SIZE 0x620
@@ -198,8 +203,7 @@
struct rx_desc *first_rx_desc;
struct rx_desc *rx_insert_ptr;
struct rx_desc *rx_ready_ptr; /* packet come pointer */
- u32 tx_packet_cnt; /* transmitted packet count */
- u32 tx_queue_cnt; /* wait to send packet count */
+ u32 tx_live_cnt;/* number of used/live tx slots */
u32 rx_avail_cnt; /* available rx descriptor count */
u32 interval_rx_cnt;/* rx packet count a callback time */
@@ -423,9 +427,17 @@
for (i = 0; i < 64; i++)
((u16 *) db->srom)[i] = read_srom_word(pci_iobase, i);
+ printk(KERN_INFO "%s: Davicom DM%04lx at 0x%lx,",
+ dev->name,
+ ent->driver_data >> 16,
+ pci_iobase);
+
/* Set Node address */
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 6; i++) {
dev->dev_addr[i] = db->srom[20 + i];
+ printk("%c%02x", i ? ':' : ' ', dev->dev_addr[i]);
+ }
+ printk(", IRQ %d\n", pci_irqline);
return 0;
@@ -490,8 +502,6 @@
/* system variable init */
db->cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
- db->tx_packet_cnt = 0;
- db->tx_queue_cnt = 0;
db->rx_avail_cnt = 0;
db->link_failed = 0;
db->wait_reset = 0;
@@ -595,46 +605,38 @@
{
struct dmfe_board_info *db = dev->priv;
struct tx_desc *txptr;
+ static unsigned pkt_num = TX_IRQ_THR;
DMFE_DBUG(0, "dmfe_start_xmit", 0);
-
- netif_stop_queue(dev);
-
- /* Too large packet check */
- if (skb->len > MAX_PACKET_SIZE) {
- printk(KERN_ERR "%s: oversized frame (%d bytes) for transmit.\n",
dev->name, (u16) skb->len);
- dev_kfree_skb(skb);
- return 0;
- }
- /* No Tx resource check, it never happen nromally */
- if (db->tx_packet_cnt >= TX_FREE_DESC_CNT) {
- return 1;
- }
/* transmit this packet */
txptr = db->tx_insert_ptr;
memcpy((char *) txptr->tx_buf_ptr, (char *) skb->data, skb->len);
- txptr->tdes1 = 0xe100 | skb->len;
+ if (--pkt_num == 0)
+ {
+ txptr->tdes1 = 0xe100 | skb->len;
+ pkt_num = TX_IRQ_THR;
+ }
+ else
+ txptr->tdes1 = 0x6100 | skb->len;
+
+ /* Transmit Packet Process */
+ txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
+ outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
+ dev->trans_start = jiffies; /* saved the time stamp */
/* Point to next transmit free descriptor */
- db->tx_insert_ptr = (struct tx_desc *) txptr->next_tx_desc;
+ txptr = (struct tx_desc *)txptr->next_tx_desc;
- /* Transmit Packet Process */
- if (db->tx_packet_cnt < TX_MAX_SEND_CNT) {
- txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
- db->tx_packet_cnt++;/* Ready to send count */
- outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
- } else {
- db->tx_queue_cnt++; /* queue the tx packet */
- outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
- }
+ if (txptr->tdes0 & 0x8000)
+ netif_stop_queue(dev);
- /* Tx resource check */
- if (db->tx_packet_cnt < TX_FREE_DESC_CNT)
- netif_wake_queue(dev);
+ db->tx_insert_ptr = txptr;
+ db->tx_live_cnt++;
/* free this SKB */
dev_kfree_skb(skb);
+
return 0;
}
@@ -713,12 +715,12 @@
Re: BTTV detection broken in 2.4.0-test11-pre5
Someone wrote: > > > So change the CMOS-settings so that the BIOS changes the boot order > > > from A, C, CD-ROM to C first instead. *grin* How long do you want > > > to keep playing Tic-Tac-Toe? > > > > Writeprotect the flashbios with the motherboard jumper, and remove the > > cmos battery. The "writeprotect flashbios" usually only protects the bottom 8k of the CMOS. That's the part that you still need to boot the system to reflash it should somehow your flash be nuked. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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: Odd behaviour with agpgart
Petr Vandrovec wrote: > > On Sat, Nov 18, 2000 at 10:43:20PM -0500, John Cavan wrote: > > Bus 1, device 0, function 0: > > VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). > > IRQ 16. > > Master Capable. Latency=64. Min Gnt=16.Max Lat=32. > > Prefetchable 32 bit memory at 0xf600 [0xf7ff]. > > Non-prefetchable 32 bit memory at 0xfeafc000 [0xfeaf]. > > Non-prefetchable 32 bit memory at 0xfe00 [0xfe7f]. > > > > But agpgart sets up: > > > > agpgart: Maximum main memory to use for agp memory: 440M > > agpgart: Detected Intel 440BX chipset > > agpgart: AGP aperture is 32M @ 0xfa00 > > AGP aperture is feature of host bridge: > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) > Flags: bus master, medium devsel, latency 32 > Memory at d000 (32-bit, prefetchable) [size=64M] > ^^ > Capabilities: [a0] AGP version 1.0 > > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) >(prog-if 00 [VGA]) > Subsystem: Matrox Graphics, Inc. Millennium G200 AGP > Flags: bus master, medium devsel, latency 32, IRQ 11 > Memory at d800 (32-bit, prefetchable) [size=16M] > Memory at d400 (32-bit, non-prefetchable) [size=16K] > Memory at d500 (32-bit, non-prefetchable) [size=8M] > Expansion ROM at [disabled] [size=64K] > Capabilities: [dc] Power Management version 1 > Capabilities: [f0] AGP version 1.0 > > So it matters what you have listed in 00:00.0 node, not on Matrox device. Ah, now it makes sense. Interestingly, yours show that the bridge address is lower than the card address, mine is reversed. > > Needless to say, the two disagree and direct rendering is disabled. > > Attached is my .config for 2.4.0-test11-pre7. I've been wading through > > the code for AGP and DRM support, but nothing jumps out at me. > > > (http://www.matrox.com/mga/support/drivers/latest/home.htm) > > As matrox driver contains large BLOB which does all important things > (dualhead) usual practices about binary only software applies. Unfortunately, dual head is what I want from it. I can get dual head, but not accelerated 3D on the primary display. The stock XFree86 driver just chokes even trying dual head. Oh well. I guess I'll be waiting for Matrox to sort themselves out or for the XFree86 guys to get it. - 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: XMMS not working on 2.4.0-test11-pre7
Just a data point I'm listening to mp3s now via xmms, running 2.4.0-test11-pre7 # uname -r -s Linux 2.4.0-test11-pre7 # rpm -q xmms xmms-1.2.3-0_helix_1 the "flags/features" switch doesn't seem to hurt it: # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 451.38 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 901.12 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Pavel Machek wrote: > > Actually, I was planning on doing on putting in a hack to do something > > like that: calculate a checksum after every buffer data update and check > > it after write completion, to make sure nothing scribbled in the buffer > > in the interim. This would also pick up some bad memory problems. > > You might want to take look to a patch with crc loop option. > > It does verify during read, not during write; but that's even better because > that way you pick up problems in IO subsystem, too. You would have to store the checksums on the filesystem then, or use a verify-after-write. What I was talking about is a verify-the-buffer-didn't get scribbled. I'd then trust the hardware to report a write failure. Note that if something scribbles on your buffer between the time you put good data on it and when it gets transfered to disk, you can verify perfectly and still have a hosed filesystem. It was pointed out that you can't really do what I'm suggesting for mmaped file data, and there's some truth to that - but certainly the interval between when ->writepage gets called and when the actual buffer write happens can be secured in this way. Doing this only for metadata is also a good idea because then the overhead would be close to nil and the basic fs integrity would be protected. -- Daniel - 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: rdtsc to mili secs?
Hi! > > > Anyway, this should be solvable by checking for clock change in the > > > timer interrupt. This way we should be able to detect when the clock > > > went weird with a 10 ms accuracy. And compensate for that. It should be > > > possible to keep a 'reasonable' clock running even through the clock > > > changes, where reasonable means constantly growing and as close to real > > > time as 10 ms difference max. > > > > > > Yes, this is not perfect, but still keep every program quite happy and > > > running. > > > > No. Udelay has just gone wrong and your old ISA xxx card just crashed > > whole system. Oops. > > Yes. But can you do any better than that? Anyway, I wouldn't expect to > be able to put my old ISA cards into a recent notebook which fiddles > with the CPU speed (or STPCLK ratio). PCMCIA is just that: putting old ISA crap into modern hardware. Sorry. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - 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: Q: Linux rebooting directly into linux.
Werner Almesberger <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: > > The code wasn't trivially reusable, and the structures had a lot > > of overhead. > > There's some overhead, but I think it's not too bad. I'll give it a > try ... > > > The rebooting is done the rest is not yet. > > Ah, and I already wondered where in all the APIC code you've hidden > the magic to avoid the config data clobbering issues ;-) Nope. That just comes in two parts. The first chunk is the work on the apic so the deadlock detector can run on UP kernels. From Ingo Molanar. The second part are my cleanups so we up the apic in a sane state upon reboot. > > I agree writing the code to understand the table may be a significant > > issue. On the other hand I still think it is worth a look, being > > able to unify option parsing for multiple platforms is not a small > > gain, nor is getting out from short sighted vendor half standards. > > Well, you certainly have a point where stupid vendors and BIOS nonsense > are concerned. However, if we ignore LinuxBIOS for a moment, each > platform already has a set of configuration parameter passing conventions > imposed by the firmware. So we need to be able to handle this anyway, and > most of the information is highly platform-specific. > > LinuxBIOS is a special case, because you have your own firmware. But > what you're suggesting is basically yet another parameter format, which > needs to incorporate and possibly unify much of the information > contained in all those platform-specific formats. I'm not sure it's worth > the effort. > > And, besides, I think it complicates the kernel, because you either > have to add a parallel set of functions extracting and processing data > from the "native" or the UBE environment, or you have to add a converter > between "native" and UBE for each platform. Or do you have a better > plan ? My initial plan was to have two parallel table parsers. The ones we have now. And another based on UBE. If we find the information we need via UBE use that. If not fall back to the old way. But the tables are only half of it. Right now we have all kinds of weirdness going through the empty_zero_page at boot time. A lot of that I plan on just gather in UBE format instead of random data in random locations. Since Setup.S implements this it should be transparent to most everything. But I need to see how well that works first before I'm too commited either way. For x86 it isn't too big of a deal. For other platforms though where the Firmware comes is multiple flavors converting everything looks like it could be a real win. I guess what I'm most after is improving the linux BIOS abstraction layer. We mostly have one, and only do BIOS calls before really starting the kernel (except for some stupid BIOS standards like APM). > When I started with bootimg, I also thought that we'd need some > parameter passing mechanism, a bit similar to UBE (although I would > have tried to be more text-based). Then I realized that there are > actually only a few tables, and we can just keep them in memory. And > some of them need to be modified before we can re-use them. (Trivial > example: the boot command line. Video modes are a similar, although > much more complicated issue.) I agree with tables that we need to be careful. A lossy conversion can be a real problem. The empty_zero_page is my first canidate, and I'll see where it goes from there. One of the more ugly challenges that I've already run into is that there are multiple tables for specifying how interrupts are routed. (In modern PC irq number is dynamically assigned). I would like to have one good table than two that fight each other. But the point is that looking through the parameters and figuring out what works and what makes sense will take some doing, and I'm not promising to do any more than clean up the empty_zero_page. > > > Besides which most tables seem to contain a lot of information that > > is probeable. Which just makes them a waste of BIOS space, and > > sources of bugs. > > Agreed with BIOS bugs ;-) Where probing is possible, is it reliable ? > It'd take some baroque BIOS parameter table over yet another mandatory > boot command line parameter any time ... > > > Hmm. I wonder how hard it would be to add -fPIC to the compilation > > line for that file. But I'm not certain that would do what I want > > in this instance... > > Are there actually architectures where the compiler generates > position-dependent code even if you're careful ? (I.e. all functions > inlined, only auto variables.) I don't know yet. And since that part is machine specific, x86 is really the only case that matters. I just don't quite trust the compiler. But next rev I'll make certain to steal this code from bootimg. Given a normal architecture I believe no references to global data should be sufficient, to ensure the code is pic. Inlines are interesting because they aren't always inlined. T
Re: Advanced Linux Kernel/Enterprise Linux Kernel
Hi! > > book, Ext2 throws safety to the wind to achieve speed. This also ties > > into Linux' convoluted VM system, and is shot in the foot by NFS. We > > would need minimally a journaled filesystem and a clean VM design, > > probably with a unified cache (no separate buffer, directory entry and > > page caches). The Tux2 Phase Trees look to be a good step in the > > direction as well, in terms of FS reliability. The filesystem would have > > to do checksums on every block. > > Actually, I was planning on doing on putting in a hack to do something > like that: calculate a checksum after every buffer data update and check > it after write completion, to make sure nothing scribbled in the buffer > in the interim. This would also pick up some bad memory problems. You might want to take look to a patch with crc loop option. It does verify during read, not during write; but that's even better because that way you pick up problems in IO subsystem, too. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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] swap= kernel commandline
Hi1 > > Did you try to load an initrd on a low-memory machine? > > It shouldn't work and it probably won't ;) > > You must be really low on memory ;-) > > # zcat initrd.gz | wc -c > 409600 > > (ash, pwd, chroot, pivot_root, smount, and still about 82 kB free.) Your solution requires 400K initrd _plus_ memory for ash and swapon. That might be easily 600K total. Yes I could imagine machine with freemem less than that. However such machines do not usually have swap available. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: test11-pre6 still very broken
Hi! > >One note for the archives, if you are presented a choice between a OHCI > >or a UHCI controller, go for the OHCI. It has a "cleaner" interface, > >handles more of the logic in the silicon, and due to this provides > >faster transfers. > > I'd disagree. UHCI has tons of advantages, not the least of which is > [Cthat it was there first and is widely available. If OHCI hadn't been > done we'd have _one_ nice good USB controller implementation instead of > fighting stupid and unnecessary battles that shouldn't have existed in > the first place. UHCI has one bad disadvantage: the way it is designed, you can choose either slow USB or slow system. If you are doing bulk usb transfers at high speed (faster than ISDN modem, or so), you need to make loop in the command "tree", which hogs down your PCI bus (leading to slow overall performance). It is called FSBR and its ugly. 50% system slowdown due to stupid UHCI. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: "No IRQ known for interrupt pin A..." error message
Martin Mares <[EMAIL PROTECTED]> writes: > > During boot, I get the message: > > > > PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try > > using pci=biosirq. > > Can you send me 'lspci -vvx' output, please? > i am not the original poster, but i get the same message (save for the device number), i.e. "PCI: No IRQ known for interrupt pin A of device 05:00.0. Please try using pci=biosirq". this is on a dell latitude running 2.4.0-test11-pre7. the output from 'lspci -vvx' follows: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disabled) (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 a8 82 00 10: 00 00 00 10 00 00 00 02 00 01 01 b0 00 00 40 10 20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 10 00 00 30: fc 10 00 00 00 14 00 00 fc 14 00 00 0b 01 c0 05 40: 28 10 74 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) Subsystem: Dell Computer Corporation: Unknown device 0074 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 a8 82 00 10: 00 10 00 10 00 00 00 02 00 05 05 b0 00 00 c0 10 20: 00 f0 ff 10 00 00 00 11 00 f0 3f 11 00 18 00 00 30: fc 18 00 00 00 1c 00 00 fc 1c 00 00 0b 02 00 05 40: 28 10 74 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Re: Odd behaviour with agpgart
On Sat, Nov 18, 2000 at 10:43:20PM -0500, John Cavan wrote: > Bus 1, device 0, function 0: > VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). > IRQ 16. > Master Capable. Latency=64. Min Gnt=16.Max Lat=32. > Prefetchable 32 bit memory at 0xf600 [0xf7ff]. > Non-prefetchable 32 bit memory at 0xfeafc000 [0xfeaf]. > Non-prefetchable 32 bit memory at 0xfe00 [0xfe7f]. > > But agpgart sets up: > > agpgart: Maximum main memory to use for agp memory: 440M > agpgart: Detected Intel 440BX chipset > agpgart: AGP aperture is 32M @ 0xfa00 AGP aperture is feature of host bridge: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) Flags: bus master, medium devsel, latency 32 Memory at d000 (32-bit, prefetchable) [size=64M] ^^ Capabilities: [a0] AGP version 1.0 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G200 AGP Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at d800 (32-bit, prefetchable) [size=16M] Memory at d400 (32-bit, non-prefetchable) [size=16K] Memory at d500 (32-bit, non-prefetchable) [size=8M] Expansion ROM at [disabled] [size=64K] Capabilities: [dc] Power Management version 1 Capabilities: [f0] AGP version 1.0 So it matters what you have listed in 00:00.0 node, not on Matrox device. > Needless to say, the two disagree and direct rendering is disabled. > Attached is my .config for 2.4.0-test11-pre7. I've been wading through > the code for AGP and DRM support, but nothing jumps out at me. > (http://www.matrox.com/mga/support/drivers/latest/home.htm) As matrox driver contains large BLOB which does all important things (dualhead) usual practices about binary only software applies. Best regards, Petr Vandrovec [EMAIL PROTECTED] - 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: BTTV detection broken in 2.4.0-test11-pre5
On Mon, 20 Nov 2000, Keith Owens wrote: > On 19 Nov 2000 12:56:17 GMT, > [EMAIL PROTECTED] (Gerd Knorr) wrote: > >Some generic way to make module args available as kernel args too > >would be nice. Or at least some simple one-liner I could put next to > >the MODULE_PARM() macro... > > On my list for 2.5. If foo is declared as MODULE_PARM in object bar > then you will be able to boot with bar.foo=27 or even foo=27 as long as > variable foo is unique amongst all objects in the kernel. Cool. Any plans how to handle drivers which are build from multiple object files like bttv? Think "bar" needs to be configurable handle this nicely. bttv should have bttv.card=xxx because the module is called "bttv", but the source file where the card insmod option is declared is bttv-cards.c ... Gerd -- Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse jedes Softwareherstellers kennen, aber keines der Produkte auch nur ansatzweise bedienen können.-- Benedict Mangelsdorff - 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: reordering pci interrupts?
Hello!
> I have a motherboard with a broken bios that is unable to set interrupts
> correctly, i.e. it initializes the devices corerctly but swaps the
> interrupts for slot1/slot3 and slot2/slot4.
>
> Now, is there a way to forcefully re-order the pci-interrupts? I do not
> have an io-apic (thus no pirq=xxx), and I tried to poke the interrupt
> values directly into /proc/bus/pic/*/*, but the kernel has it's own idea.
>
> Thanks a lot for any info (I guess I'll just patch the kernel).
Please try this patch and boot with "pci=autoirq" on the kernel command line.
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"veni, vidi, nuclei deceiri - I came, I saw, I core dumped"
--- arch/i386/kernel/pci-pc.c.mjSun Nov 19 20:18:14 2000
+++ arch/i386/kernel/pci-pc.c Sun Nov 19 20:18:14 2000
@@ -1035,6 +1035,9 @@
} else if (!strncmp(str, "lastbus=", 8)) {
pcibios_last_bus = simple_strtol(str+8, NULL, 0);
return NULL;
+ } else if (!strcmp(str, "autoirq")) {
+ pci_probe |= PCI_AUTOIRQ;
+ return NULL;
}
return str;
}
--- arch/i386/kernel/pci-i386.h.mj Sun Nov 19 20:18:32 2000
+++ arch/i386/kernel/pci-i386.h Sun Nov 19 20:18:32 2000
@@ -18,6 +18,7 @@
#define PCI_NO_SORT 0x100
#define PCI_BIOS_SORT 0x200
#define PCI_NO_CHECKS 0x400
+#define PCI_AUTOIRQ 0x800
#define PCI_ASSIGN_ROMS 0x1000
#define PCI_BIOS_IRQ_SCAN 0x2000
--- arch/i386/kernel/pci-irq.c.mj Sun Nov 19 20:18:50 2000
+++ arch/i386/kernel/pci-irq.c Sun Nov 19 20:18:50 2000
@@ -487,7 +487,7 @@
* If the BIOS has set an out of range IRQ number, just ignore it.
* Also keep track of which IRQ's are already in use.
*/
- if (dev->irq >= 16) {
+ if (dev->irq >= 16 || (pci_probe & PCI_AUTOIRQ)) {
DBG("%s: ignoring bogus IRQ %d\n", dev->slot_name, dev->irq);
dev->irq = 0;
}
-
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: "No IRQ known for interrupt pin A..." error message
Hello! > During boot, I get the message: > > PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try > using pci=biosirq. Can you send me 'lspci -vvx' output, please? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "System going down at 1:45 for disk crashing." - 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] semaphore fairness patch against test11-pre6
On Sun, 19 Nov 2000, Andrew Morton wrote:
>
> I don't see a path where David's patch can cause a lost wakeup in the
> way you describe.
Basically, if there are two up() calls, they might end up waking up only
one process, because the same process goes to sleep twice. That's wrong.
It should wake up two processes.
However, thinking about it more, that's obviously possible only for
semaphores that are used for more than just mutual exclusion, and
basically nobody does that anyway.
> Next step is to move the waitqueue and wakeup operations so they're
> inside the spinlock. Nope. That doesn't work either.
>
> Next step is to throw away the semaphore_lock and use the sem->wait
> lock instead. That _does_ work. This is probably just a
> fluke - it synchronises the waker with the sleepers and we get lucky.
Yes, especially on a two-cpu machine that kind of synchronization can
basically end up hiding real bugs.
I'll think about this some more. One thing I noticed is that the
"wake_up(&sem->wait);" at the end of __down() is kind of bogus: we don't
actually want to wake anybody up at that point at all, it's just that if
we don't wake anybody up we'll end up having "sem = 0, sleeper = 0", and
when we unlock the semaphore the "__up()" logic won't trigger, and we
won't ever wake anybody up. That's just incredibly bogus.
Instead of the "wake_up()" at the end of __down(), we should have
something like this at the end of __down() instead:
... for-loop ...
}
tsk->state = TASK_RUNNING;
remove_wait_queue(&sem->wait, &wait);
/* If there are others, mark the semaphore active */
if (wait_queue_active(&sem_wait)) {
atomic_dec(&sem->count);
sem->sleepers = 1;
}
spin_unlock_irq(&semaphore_lock);
}
which would avoid an unnecessary reschedule, and cause the wakeup to
happen at the proper point, namely "__up()" when we release the
semaphore.
I suspect this may be part of the trouble with the "sleepers" count
playing: we had these magic rules that I know I thought about when the
code was written, but that aren't really part of the "real" rules.
Linus
-
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: BTTV detection broken in 2.4.0-test11-pre5
On Sun, 19 Nov 2000, David Lang wrote: > there is a rootkit kernel module out there that, if loaded onto your > system, can make it almost impossible to detect that your system has been > compramised. with module support disabled this isn't possible. Wrong. I've seen messages on bugtraq saying it is possible to "load" modules into the kernel by patching /dev/kmem. Even for loading modules custom modules the normal way the attacker needs root priviliges (unless you have a world-writeable /lib/modules...). If this is the case it is too late anyway... Gerd - 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: PROBLEM: isofs crash on 2.4.0-test11-pre7 [1.] MAINTAINERS: ISO FILESYSTEM
Hi Vincent and Tony, Hate to spoil the fun :( but, try the patch Tom Leete commited on Saturday november 18th. Since your Oopses are related to get_joliet_filename(), this might just do the trick? Luuk >Hi, > > >The second and third arguments of get_joliet_filename() are swapped. > > >Tom > > > >--- linux-2.4.0-test11/fs/isofs/namei.c.orig Sat Nov 18 01:55:55 2000 >+++ linux-2.4.0-test11/fs/isofs/namei.c Sat Nov 18 07:08:05 2000 >@@ -127,7 +127,7 @@ > dpnt = tmpname; > #ifdef CONFIG_JOLIET > } else if (dir->i_sb->u.isofs_sb.s_joliet_level) >- dlen = get_joliet_filename(de, dir, tmpname); >+ dlen = get_joliet_filename(de, tmpname, dir); >dpnt = tmpname; >#endif > } else if (dir->i_sb->u.isofs_sb.s_mapping == 'a') >- - 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: XMMS not working on 2.4.0-test11-pre7
On Sun, 19 Nov 2000, David Ford wrote: > > My guess is that it's a plugin, the source for xmms doesn't have "cpuinfo" anywhere >in it. > > -d > > Gianluca Anzolin wrote: > > > it seems there has been a change in the format of the /proc/cpuinfo file: infact >'flags: ' became 'features: ' > > > > This change broke xmms and could broke any other program which relies on >/proc/cpuinfo... > > > > I hope the problem will be solved (in the kernel or in every other program which >uses /proc/cpuinfo) soon... Are you using the 3Dnow input MP3 decoder plugin? This certainly attempts to identify the CPU, so it can determine which decoder to use. James. - 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: Freeze on FPU exception with Athlon
--- Brian Gerst <[EMAIL PROTECTED]> wrote: > > Ok, that was it! It's IRQ 13. Guess I should have > > tried that first. Now everything works perfectly. > > Thanks everybody. > > What motherboard do you have? I can't reproduce > this on my FIC SD11. > > -- > > Brian Gerst It's a ABIT KT7-100 RAID. And I know somebody else who has the same problem with this board. So it seems definitely board related. -- Markus __ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Gratis zum Millionär! - http://10millionenspiel.yahoo.de - 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: PROBLEM: 3c509 driver broken in 2.4.0-test10, not in -test9
Peter Rottengatter wrote: > > Sorry for using this address, there does not appear to be a special maintainer > for the 3c509 network driver. > > 1. > 3c509 driver broken in 2.4.0-test10, not in -test9 > > 2. > The 3c509 network driver worked fine for decades almost ;-) that is 2.0.x, > 2.2.x, and 2.4.0-test up to 9. In 2.4.0-test10 it opes upon modprobing. > lsmod says "initializing" in the 3c509 entry, forever. > > 3. > 3c509, 3C509, Ethernet, networking, 2.4.0-test10 fixed in test11-preXX -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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/
PROBLEM: 3c509 driver broken in 2.4.0-test10, not in -test9
Sorry for using this address, there does not appear to be a special maintainer for the 3c509 network driver. 1. 3c509 driver broken in 2.4.0-test10, not in -test9 2. The 3c509 network driver worked fine for decades almost ;-) that is 2.0.x, 2.2.x, and 2.4.0-test up to 9. In 2.4.0-test10 it opes upon modprobing. lsmod says "initializing" in the 3c509 entry, forever. 3. 3c509, 3C509, Ethernet, networking, 2.4.0-test10 4. Linux version 2.4.0-test10 compiled by root@arisia (#3 Fri Nov 17 22:37:22 CET 2000) using gcc version 2.95.2 2220 (Debian GNU/Linux) 5. Nov 19 17:26:37 arisia kernel: Unable to handle kernel NULL pointer dereference at virtual address 0070 Nov 19 17:26:37 arisia kernel: printing eip: Nov 19 17:26:37 arisia kernel: ca8e635c Nov 19 17:26:37 arisia kernel: *pde = Nov 19 17:26:37 arisia kernel: Oops: 0002 Nov 19 17:26:37 arisia kernel: CPU:0 Nov 19 17:26:37 arisia kernel: EIP:0010:[sg:sg_big_buff+484244/85376260] Nov 19 17:26:37 arisia kernel: EFLAGS: 00010202 Nov 19 17:26:37 arisia kernel: eax: 2e976000 ebx: 0004 ecx: c01fd8f0 edx: 0070 Nov 19 17:26:37 arisia kernel: esi: 0003 edi: 0300 ebp: c6d57f3c esp: c6d57f0c Nov 19 17:26:37 arisia kernel: ds: 0018 es: 0018 ss: 0018 Nov 19 17:26:37 arisia kernel: Process modprobe (pid: 448, stackpage=c6d57000) Nov 19 17:26:37 arisia kernel: Stack: ca8e604e ca8e6048 c6d57f2c 0070 0003 000f Nov 19 17:26:37 arisia kernel:ca8e604e ca8e6048 c1044010 c01fea6c 2e976000 f987 ca8e6fb9 Nov 19 17:26:37 arisia kernel:ca8e6000 c011689b c6d56000 400279c8 bfffdf94 bfffdf54 c6078000 Nov 19 17:26:37 arisia kernel: Call Trace: [sg:sg_big_buff+483462/85377042] [sg:sg_big_buff+483456/85377048] [sg:sg_big_buff+483462/85377042] [sg:sg_big_buff+483456/85377048] [sg:sg_big_buff+487409/85373095] [sg:sg_big_buff+483384/85377120] [sys_init_module+979/1104] Nov 19 17:26:37 arisia kernel:[sg:sg_big_buff+446520/85413984] [sg:sg_big_buff+483456/85377048] [system_call+51/64] Nov 19 17:26:37 arisia kernel: Code: 89 02 8b 44 24 34 66 89 42 04 8b 44 24 3c 89 78 20 8b 54 24 ksymoops adds: Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 89 02 mov%eax,(%edx) Code; 0002 Before first symbol 2: 8b 44 24 34 mov0x34(%esp,1),%eax Code; 0006 Before first symbol 6: 66 89 42 04 mov%ax,0x4(%edx) Code; 000a Before first symbol a: 8b 44 24 3c mov0x3c(%esp,1),%eax Code; 000e Before first symbol e: 89 78 20 mov%edi,0x20(%eax) Code; 0011 Before first symbol 11: 8b 54 24 00 mov0x0(%esp,1),%edx 6. Just issue "modprobe 3c509" like this: # modprobe 3c509 Segmentation fault # lsmod Module Size Used by 3c509 5920 1 (initializing) af_packet 7904 0 (autoclean) parport_pc 13280 1 (autoclean) lp 4464 0 (autoclean) parport14848 1 (autoclean) [parport_pc lp] hisax 143760 5 ramfs 2208 1 (autoclean) serial 40816 0 (autoclean) opl3 11088 0 (unused) sb 1744 0 sb_lib 33328 0 [sb] uart401 6224 0 [sb_lib] sound 55648 0 [opl3 sb_lib uart401] sg 20960 0 (unused) slip6080 0 (unused) dummy 1152 1 isdn 102704 6 [hisax] ipv6 115120 -1 binfmt_misc 3296 0 7. 7.1 # sh /usr/src/linux/scripts/ver_linux -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux arisia 2.4.0-test10 #3 Fri Nov 17 22:37:22 CET 2000 i586 unknown Kernel modules 2.3.19 Gnu C 2.95.2 Gnu Make 3.78.1 Binutils 2.9.5.0.37 Linux C Library2.1.95 Dynamic linker ldd (GNU libc) 2.1.95 Procps 2.0.6 Mount 2.10f Net-tools 2.05 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded 3c509 af_packet parport_pc lp parport hisax ramfs serial opl3 sb sb_lib uart401 sound sg slip dummy isdn ipv6 binfmt_misc 7.2 # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 9 model name : AMD-K6(tm) 3D+ Processor stepping: 1 cpu MHz : 400.000915 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 se
Re: [PATCH] Large "clipped" IDE disk support for 2.4 when using old BIOS
On Sun, Nov 19, 2000 at 04:30:34AM +0900, Taisuke Yamada wrote:
> Earlier this month, I had sent in a patch to 2.2.18pre17 (with
> IDE-patch from http://www.linux-ide.org/ applied) to add support
> for IDE disk larger than 32GB, even if the disk required "clipping"
> to reduce apparent disk size due to BIOS limitation.
>
> BIOS known to have this limitation is Award 4.51 (and before) and
> it seems many mainboards with not-so-great vendor support still use it.
>
> Now I'm moving to 2.4-based system, and so ported the patch to
> 2.4-test10. It also applies cleanly to 2.4-test11.
>
> With this patch, you will be able to use disk capacity above
> 32GB (or 2GB/8GB depending on how clipping take effect), and
> still be able to boot off from the disk because you can leave
> the "clipping" turned on.
Hi Taisuke,
I suppose you know that no kernel patch is required
(since setmax.c does the same from user space).
Did you try setmax?
I would like to see the results - am still in the information
gathering stage - I have two largish Maxtor disks myself, one
40 GB and one 60 GB, and their behaviour is different, so
to me it seems a bit too early to come with kernel patches.
I think I already sent you setmax.c, but in case my memory
is confused let me include it here again. This is for 2.4.
Andries
-
/* setmax.c - aeb, 000326 */
#include
#include
#include
#include
#ifndef HDIO_DRIVE_CMD_AEB
#define HDIO_DRIVE_CMD_AEB 0x031e
#endif
#define INITIALIZE_DRIVE_PARAMETERS 0x91
#define READ_NATIVE_MAX_ADDRESS 0xf8
#define CHECK_POWER_MODE0xe5
#define SET_MAX 0xf9
#define LBA 0x40
#define VV 1 /* if set in sectorct then NOT volatile */
struct idecmdin {
unsigned char cmd;
unsigned char feature;
unsigned char nsect;
unsigned char sect, lcyl, hcyl;
unsigned char select;
};
struct idecmdout {
unsigned char status;
unsigned char error;
unsigned char nsect;
unsigned char sect, lcyl, hcyl;
unsigned char select;
};
unsigned int
tolba(unsigned char *args) {
return ((args[6] & 0xf) << 24) + (args[5] << 16) + (args[4] << 8) + args[3];
}
void
fromlba(unsigned char *args, unsigned int lba) {
args[3] = (lba & 0xff);
lba >>= 8;
args[4] = (lba & 0xff);
lba >>= 8;
args[5] = (lba & 0xff);
lba >>= 8;
args[6] = (args[6] & 0xf0) | (lba & 0xf);
}
int
get_identity(int fd) {
unsigned char args[4+512] = {WIN_IDENTIFY,0,0,1,};
struct hd_driveid *id = (struct hd_driveid *)&args[4];
if (ioctl(fd, HDIO_DRIVE_CMD, &args)) {
perror("HDIO_DRIVE_CMD");
fprintf(stderr,
"WIN_IDENTIFY failed - trying WIN_PIDENTIFY\n");
args[0] = WIN_PIDENTIFY;
if (ioctl(fd, HDIO_DRIVE_CMD, &args)) {
perror("HDIO_DRIVE_CMD");
fprintf(stderr,
"WIN_PIDENTIFY also failed - giving up\n");
exit(1);
}
}
printf("lba capacity: %d sectors (%lld bytes)\n",
id->lba_capacity,
(long long) id->lba_capacity * 512);
}
/*
* result: in LBA mode precisely what is expected
* in CHS mode the correct H and S, and C mod 65536.
*/
unsigned int
get_native_max(int fd, int slave) {
unsigned char args[7];
int i, max;
for (i=0; i<7; i++)
args[i] = 0;
args[0] = READ_NATIVE_MAX_ADDRESS;
args[6] = (slave ? 0x10 : 0) | LBA;
if (ioctl(fd, HDIO_DRIVE_CMD_AEB, &args)) {
perror("HDIO_DRIVE_CMD_AEB failed READ_NATIVE_MAX_ADDRESS");
for (i=0; i<7; i++)
printf("%d = 0x%x\n", args[i], args[i]);
exit(1);
}
return tolba(args);
}
/*
* SET_MAX_ADDRESS requires immediately preceding READ_NATIVE_MAX_ADDRESS
*
* Results: this fails for delta <= 254, succeeds for delta >= 255.
* So, in order to get the last 255*512=130560 bytes back one has to reboot.
* Side effect: reset to CurCHS=16383/16/63, CurSects=16514064.
*/
void
set_max_address(int fd, int slave, int delta) {
unsigned char args[7];
int i, nativemax;
nativemax = get_native_max(fd, slave);
printf("nativemax=%d (0x%x)\n", nativemax, nativemax);
for (i=0; i<7; i++)
args[i] = 0;
args[0] = SET_MAX;
args[1] = 0;
fromlba(args, nativemax-delta);
args[6] |= LBA;
if (ioctl(fd, HDIO_DRIVE_CMD_AEB, &args)) {
perror("HDIO_DRIVE_CMD_AEB failed SET_MAX");
for (i=0; i<7; i++)
printf("%d = 0x%x\n", args[i], args[i]);
exit(1);
}
}
static char short_opts[] = "d:";
static const struct option long_opts[] = {
{ "delta", required_argument,
2.4.0-test11-pre3: kernel: Attempt to read inode for relocated directory
2.4.0-test11-pre3 kernel said Nov 19 17:40:25 iapetus kernel: Attempt to read inode for relocated directory Nov 19 17:40:25 iapetus last message repeated 8 times while doing a mount -t iso9660 /dev/hdc /cdrom cd /cdrom find -depth |cpio -pdm /dst Is reproducable here, both by loopback mounting the iso9660 image as by mounting the CD-RW where it has been written to. -- Frank - 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: BTTV detection broken in 2.4.0-test11-pre5
> > So change the CMOS-settings so that the BIOS changes the boot order > > from A, C, CD-ROM to C first instead. *grin* How long do you want > > to keep playing Tic-Tac-Toe? > > Writeprotect the flashbios with the motherboard jumper, and remove the > cmos battery. > > Checkmate. :-) You can do a live Linux kernel swap without a bios level reboot. Alan - 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] Large "clipped" IDE disk support for 2.4 when using oldBIOS
The original was good, but the changes made to do the callout fail to
return structs that need to be filled. This is my fault.
On Sun, 19 Nov 2000, Dan Aloni wrote:
> On Sun, 19 Nov 2000, Taisuke Yamada wrote:
>
> > Earlier this month, I had sent in a patch to 2.2.18pre17 (with
> > IDE-patch from http://www.linux-ide.org/ applied) to add support
> > for IDE disk larger than 32GB, even if the disk required "clipping"
> > to reduce apparent disk size due to BIOS limitation.
> >
> > [...] patch
>
> This patch is not good. It compiles, but when I boot the kernel, it
> decides to ignore the hdc=5606,255,63 parameter that I pass to the kernel,
> and limits the number of sectors to fill 8.4GB.
>
> (from dmesg:)
>
> hdc: lba = 0, cap = 16514064
> hdc: 16514064 sectors (8455 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(33)
>
> Notes:
> * Notice the contradiction between 16414064 sectors and 5606/255/63
>geometry, something is definitly wrong there.
> * I *didn't* change the jumper settings to 'clipping' mode, only the
>kernel was modified in this test.
> * When I try to read (using dd) from somewhere above the 40GB offset in
>the drive, no success. I guess if I tried to read pass 8.4GB it
>wouldn't have yield success either.
> * In this test, the code in the patch doesn't printk() anything except
>that 'hdc: lba = 0, cap = 16514064' line.
> * Normally, without the patch I get:
>
> hdc: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63,
> UDMA(33)
>
>And then there's no problem reading any offset on the drive.
>
> * I really need this sort of patch, tired of booting the computer from a
>floppy...
> * The patch didn't want to apply for some reason, so I had to apply the
>patch manually (to test11-pre7).
>
>Here is the version of patch that does apply: (please release an
>updated patch)
>
> --- linux/drivers/ide/ide-disk.c Sun Nov 19 17:15:56 2000
> +++ linux/drivers/ide/ide-disk.c Sun Nov 19 17:27:31 2000
> @@ -513,24 +513,149 @@
> current_capacity(drive));
> }
>
> +
> +/*
> + * Tests if the drive supports Host Protected Area feature.
> + * Returns true if supported, false otherwise.
> + */
> +static inline int idedisk_supports_host_protected_area(ide_drive_t *drive)
> +{
> +int flag = (drive->id->command_set_1 & 0x0a) ? 1 : 0;
> +printk("%s: host protected area => %d\n", drive->name, flag);
> +return flag;
> +}
> +
> +/*
> + * Queries for true maximum capacity of the drive.
> + * Returns maximum LBA address (> 0) of the drive, 0 if failed.
> + */
> +static unsigned long idedisk_read_native_max_address(ide_drive_t *drive)
> +{
> +byte args[7];
> +unsigned long addr = 0;
> +
> +printk("%s: checking for max native LBA...\n", drive->name);
> +
> +/* Create IDE/ATA command request structure
> + *
> + * NOTE: I'm not sure if I can safely use IDE_*_OFFSET macro
> + * here...For real ATA command structure, offset for IDE
> + * command is 7, but in IDE driver, it needs to be at 0th
> + * index (same goes for IDE status offset below). Hmm...
> + */
> +args[0] = 0xf8; /* READ_NATIVE_MAX - see ATA spec */
> +args[IDE_FEATURE_OFFSET] = 0x00;
> +args[IDE_NSECTOR_OFFSET] = 0x00;
> +args[IDE_SECTOR_OFFSET] = 0x00;
> +args[IDE_LCYL_OFFSET]= 0x00;
> +args[IDE_HCYL_OFFSET]= 0x00;
> +args[IDE_SELECT_OFFSET] = 0x40;
> +
> +/* submit command request - if OK, read current max LBA value */
> +if (ide_wait_cmd_task(drive, args) == 0) {
> +if ((args[0] & 0x01) == 0) {
> +addr = ((args[IDE_SELECT_OFFSET] & 0x0f) << 24)
> + | ((args[IDE_HCYL_OFFSET] ) << 16)
> + | ((args[IDE_LCYL_OFFSET] ) << 8)
> + | ((args[IDE_SECTOR_OFFSET] ));
> +}
> +}
> +
> +printk("%s: max native LBA is %lu\n", drive->name, addr);
> +
> +return addr;
> +}
> +
> +/*
> + * Sets maximum virtual LBA address of the drive.
> + * Returns new maximum virtual LBA address (> 0) or 0 on failure.
> + */
> +static unsigned long idedisk_set_max_address(ide_drive_t *drive,
> + unsigned long addr_req)
> +{
> +byte args[7];
> +unsigned long addr_set = 0;
> +
> +printk("%s: (un)clipping max LBA...\n", drive->name);
> +
> +/* Create IDE/ATA command request structure
> + *
> + * NOTE: I'm not sure if I can safely use IDE_*_OFFSET macro
> + * here...For real ATA command structure, offset for IDE
> + * command is 7, but in IDE driver, it needs to be at 0th
> + * index (same goes for IDE status offset below). Hmm...
> + */
> +args[0] = 0xf9; /* SET_MAX - see ATA spec */
> + args[IDE_FEATURE_OFFSET] = 0x00;
> +args[IDE_NSECTOR_OFFSET] = 0x00;
> +args[IDE_SECTOR_OFFSET] = ((addr_req ) & 0xff);
> +args[IDE_
Re: How to add a drive to DMA black list?
At 11:26 17/11/2000, Alan Cox wrote: > > drive problem, considering that another ide drive on the same controller > > works fine with DMA enabled (a QUANTUM TRB850A) while the Conner > > Peripherals 1275MB - CFS1275A fails with DMA enabled. They are in fact > both > >And the Conner drives work fine on a VIA MVP3 it seems. You need to try >the drive with multiple controllers to be sure its not a PIIX bug that only >trips on that drive (or indeed a bug in the combination) I have now tried the drive (which is actually a seagate drive but it identifies itself as a conner) on my new Promise ATA-100 controller and the drive works fine with DMA enabled. So you were quite right, it's the PIIX driver/tuning which kills it. Anton -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein -- Anton Altaparmakov Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile) Christ's CollegeeMail: [EMAIL PROTECTED] / [EMAIL PROTECTED] Cambridge CB2 3BUICQ: 8561279 United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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] Large "clipped" IDE disk support for 2.4 when using oldBIOS
On Sun, 19 Nov 2000, Taisuke Yamada wrote:
> Earlier this month, I had sent in a patch to 2.2.18pre17 (with
> IDE-patch from http://www.linux-ide.org/ applied) to add support
> for IDE disk larger than 32GB, even if the disk required "clipping"
> to reduce apparent disk size due to BIOS limitation.
>
> [...] patch
This patch is not good. It compiles, but when I boot the kernel, it
decides to ignore the hdc=5606,255,63 parameter that I pass to the kernel,
and limits the number of sectors to fill 8.4GB.
(from dmesg:)
hdc: lba = 0, cap = 16514064
hdc: 16514064 sectors (8455 MB) w/1916KiB Cache, CHS=5606/255/63, UDMA(33)
Notes:
* Notice the contradiction between 16414064 sectors and 5606/255/63
geometry, something is definitly wrong there.
* I *didn't* change the jumper settings to 'clipping' mode, only the
kernel was modified in this test.
* When I try to read (using dd) from somewhere above the 40GB offset in
the drive, no success. I guess if I tried to read pass 8.4GB it
wouldn't have yield success either.
* In this test, the code in the patch doesn't printk() anything except
that 'hdc: lba = 0, cap = 16514064' line.
* Normally, without the patch I get:
hdc: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=5606/255/63,
UDMA(33)
And then there's no problem reading any offset on the drive.
* I really need this sort of patch, tired of booting the computer from a
floppy...
* The patch didn't want to apply for some reason, so I had to apply the
patch manually (to test11-pre7).
Here is the version of patch that does apply: (please release an
updated patch)
--- linux/drivers/ide/ide-disk.cSun Nov 19 17:15:56 2000
+++ linux/drivers/ide/ide-disk.cSun Nov 19 17:27:31 2000
@@ -513,24 +513,149 @@
current_capacity(drive));
}
+
+/*
+ * Tests if the drive supports Host Protected Area feature.
+ * Returns true if supported, false otherwise.
+ */
+static inline int idedisk_supports_host_protected_area(ide_drive_t *drive)
+{
+int flag = (drive->id->command_set_1 & 0x0a) ? 1 : 0;
+printk("%s: host protected area => %d\n", drive->name, flag);
+return flag;
+}
+
+/*
+ * Queries for true maximum capacity of the drive.
+ * Returns maximum LBA address (> 0) of the drive, 0 if failed.
+ */
+static unsigned long idedisk_read_native_max_address(ide_drive_t *drive)
+{
+byte args[7];
+unsigned long addr = 0;
+
+printk("%s: checking for max native LBA...\n", drive->name);
+
+/* Create IDE/ATA command request structure
+ *
+ * NOTE: I'm not sure if I can safely use IDE_*_OFFSET macro
+ * here...For real ATA command structure, offset for IDE
+ * command is 7, but in IDE driver, it needs to be at 0th
+ * index (same goes for IDE status offset below). Hmm...
+ */
+args[0] = 0xf8; /* READ_NATIVE_MAX - see ATA spec */
+args[IDE_FEATURE_OFFSET] = 0x00;
+args[IDE_NSECTOR_OFFSET] = 0x00;
+args[IDE_SECTOR_OFFSET] = 0x00;
+args[IDE_LCYL_OFFSET]= 0x00;
+args[IDE_HCYL_OFFSET]= 0x00;
+args[IDE_SELECT_OFFSET] = 0x40;
+
+/* submit command request - if OK, read current max LBA value */
+if (ide_wait_cmd_task(drive, args) == 0) {
+if ((args[0] & 0x01) == 0) {
+addr = ((args[IDE_SELECT_OFFSET] & 0x0f) << 24)
+ | ((args[IDE_HCYL_OFFSET] ) << 16)
+ | ((args[IDE_LCYL_OFFSET] ) << 8)
+ | ((args[IDE_SECTOR_OFFSET] ));
+}
+}
+
+printk("%s: max native LBA is %lu\n", drive->name, addr);
+
+return addr;
+}
+
+/*
+ * Sets maximum virtual LBA address of the drive.
+ * Returns new maximum virtual LBA address (> 0) or 0 on failure.
+ */
+static unsigned long idedisk_set_max_address(ide_drive_t *drive,
+ unsigned long addr_req)
+{
+byte args[7];
+unsigned long addr_set = 0;
+
+printk("%s: (un)clipping max LBA...\n", drive->name);
+
+/* Create IDE/ATA command request structure
+ *
+ * NOTE: I'm not sure if I can safely use IDE_*_OFFSET macro
+ * here...For real ATA command structure, offset for IDE
+ * command is 7, but in IDE driver, it needs to be at 0th
+ * index (same goes for IDE status offset below). Hmm...
+ */
+args[0] = 0xf9; /* SET_MAX - see ATA spec */
+ args[IDE_FEATURE_OFFSET] = 0x00;
+args[IDE_NSECTOR_OFFSET] = 0x00;
+args[IDE_SECTOR_OFFSET] = ((addr_req ) & 0xff);
+args[IDE_LCYL_OFFSET]= ((addr_req >> 8) & 0xff);
+args[IDE_HCYL_OFFSET]= ((addr_req >> 16) & 0xff);
+args[IDE_SELECT_OFFSET] = ((addr_req >> 24) & 0x0f) | 0x40;
+
+/* submit command request - if OK, read new max LBA value */
+if (ide_wait_cmd_task(drive, args) == 0) {
+if ((args[0] & 0x01) == 0) {
+addr_set = ((args[IDE_SELECT_OFFSET] & 0x0f) << 24)
+ | ((ar
Re: 2.4 sendfile() not doing as manpage promises?
On Sun, Nov 19, 2000 at 01:53:00AM +0100, bert hubert wrote: : On Sat, Nov 18, 2000 at 03:15:28PM -0800, Dan Hollis wrote: : ::: In that case, the wording of the manpage needs to be changed, as it ::: implies that 'either or both' of the filedescriptors can be sockets. :: :: Its quite clear. :: :: DESCRIPTION :: This call copies data between file descriptor and another :: file descriptor or socket. in_fd should be a file :: descriptor opened for reading. out_fd should be a :: descriptor opened for writing or a connected socket. :: :: in_fd must be a file, out_fd can be a file or socket. : : My manpages must be outdated then, my manpage is from 1 Dec 1998. Thanks for : the correction. The manpage is dated 1 Dec 1998 and reads DESCRIPTION This call copies data between one file descriptor and another. Either or both of these file descriptors may refer to a socket. in_fd should be a file descriptor opened for reading and out_fd should be a descriptor opened for writing. If that is incorrect, then editing a private copy of the manpage, as Dan Hollis, or the distributor from whom he got his page, seems to have done, does not suffice to change the manpage distribution. (Moreover, the text Dan Hollis quotes is rather strange -- also sockets give one a file descriptor, so the author of that modified man page did not know what he was talking about, or was not being precise.) Andries - 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: XMMS not working on 2.4.0-test11-pre7
My guess is that it's a plugin, the source for xmms doesn't have "cpuinfo" anywhere in it. -d Gianluca Anzolin wrote: > it seems there has been a change in the format of the /proc/cpuinfo file: infact >'flags: ' became 'features: ' > > This change broke xmms and could broke any other program which relies on >/proc/cpuinfo... > > I hope the problem will be solved (in the kernel or in every other program which >uses /proc/cpuinfo) soon... begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: BTTV detection broken in 2.4.0-test11-pre5
Christer Weinigel wrote: > >Kernel on writeprotected floppy disk... > > So change the CMOS-settings so that the BIOS changes the boot order > from A, C, CD-ROM to C first instead. *grin* How long do you want > to keep playing Tic-Tac-Toe? > > Of course, using capabilities and totally disabling access to the raw > disk devices and to any I/O ports might be the solution, provided that > there are no bugs or thinkos in the capabilities code. How much time do you want to spend hardening your system? A few simple steps can make things very hard for a remote attacker. Everyone wants to decry every tiny little step saying there are a dozen ways to get around it. But take 12 simple steps to take care of those dozen ways, and you've upped the bar sufficiently. It will take a much more skilled person to get past your defenses. Most exploits depend on a common system layout. I.e. a redhat script issue. Immediately you have hundreds of thousands of systems around the world which are probably vulnerable. If however you've only installed 10 megs worth of total system programs and kernel etc that you've carefully decided are necessary, you probably don't have those scripts. With this attention to detail, you probably shut off all those extraneous services like rpc.statd. Chances are you have a chrooted BIND and on top of that you're running 9.0.1rc2. With all that covered I'd hazard a guess that your nicely tidied up iptables are preventing access to anything you're not paying attention to. Every item you add to this hardening checklist makes your system much less of a target. First it has less of a signature on a perp's someisp.addresses.com sweep, and second, once it's found there are less and less available options for intrusion. So instead of doing nothing because someone can always infiltrate your system, do a few somethings so it raises the bar against whomever tries. Those dozen doors are great for a shopping mall, but bad for a classified room. -d begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: [PATCH] megaraid driver update for 2.4.0-test10
Miquel van Smoorenburg wrote: > > In article <[EMAIL PROTECTED]>, > dalecki <[EMAIL PROTECTED]> wrote: > >This is a multi-part message in MIME format. > >1. Merge the most current version (aka: 1.08) of the > > MegaRAID driver from AMI in to the most current kernel > > (2.4.0-test10 and friends). > > The latest is 1.11a or something. The 1.08 one has *bugs*. > At least if it's the same from the 2.2.18preX series. And even > that one has still patches outstanding because it doesn't work No it's not taken from 2.2.18. It's based on the latest stuff found on www.ami.com. And then I have fixed some issues which where directly obvious. And then it's not quite broken since it's working quite fine on the box found here. Anyway. There is some point where one has to start at ;-). - 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: BTTV detection broken in 2.4.0-test11-pre5
> Why not? /me has nearly everything compiled as modules. Some people have extensive sh, awk and sed scripts to manage their systems, some have compiled programs. > > There is an introduced security weakness by using kernels. > > ??? Guess you mean "by using modules"? Which weakness? Other than > bugs? I don't see bugs like the recent modprobe oops as major problem. > They happen (everythere), they get fixed. If your server has a kernel that doesn't support modules, then a trojan hiding module can't be used. Modules are easily tampered with and you no more the wise. > > So..what is the point in making it modular? > > It's much more flexible. > > You can reconfigure/update the driver without recompiling the kernel > and without rebooting. If the driver needs some tweaks to make it > work with your hardware you can update /etc/modules.conf and reload > the modules with the new options. If you have found a working > configuration, you can simply leave it as is. Modules are fantastic for workstations, testbeds, machines that change a lot. Servers are normally a static configuration. I won't ship a blackbox device to a customer that allows them to twiddle with things, their curiosity becomes a maintenance hassle. I have a product in the lab that uses bttv and I'd really love to be able to compile it into the kernel. > * rmmod ide-cd; modprobe ide-scsi; modprobe sr_mod (for burning CD's) > * /etc/rc.d/init.d/network stop; rmmod de4x5; modprobe tulip; >/etc/rc.d/init.d/network start (tulip manages it to drive the card >full-duplex, de4x5 doesn't). Tulip works dandy for me, I have no need of changing it and on a remote server it's not intelligent to remove your networking support and reload it. The process may fail and that leaves you dead. > Please turn this off. My vcard size is the same or smaller than the average signature. Using mime, you have the option of easily filtering vcards. Signatures aren't as easily identified for filtering. -d begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: [PATCH] megaraid driver update for 2.4.0-test10
Jeff Garzik wrote:
>
> dalecki wrote:
> > -#if LINUX_VERSION_CODE > 0x020024
> > #include
> > -#endif
>
> *cheer*
I missd this point...
>
> > -u32 RDINDOOR (mega_host_config * megaCfg)
> > +ulong RDINDOOR (mega_host_config * megaCfg)
> > -void WRINDOOR (mega_host_config * megaCfg, u32 value)
> > +void WRINDOOR (mega_host_config * megaCfg, ulong value)
> > -u32 RDOUTDOOR (mega_host_config * megaCfg)
> > +ulong RDOUTDOOR (mega_host_config * megaCfg)
> > -void WROUTDOOR (mega_host_config * megaCfg, u32 value)
> > +void WROUTDOOR (mega_host_config * megaCfg, ulong value)
>
> [unless there is a prototype not seen in the patch...] this looks like
> namespace pollution. Can you mark these 'static' ?
Agreed.
> > +#define IO_LOCK_T unsigned long io_flags;
> > #define IO_LOCK spin_lock_irqsave(&io_request_lock,io_flags);
> > #define IO_UNLOCK spin_unlock_irqrestore(&io_request_lock,io_flags);
>
> hmmm, I'm not sure if its a good idea to hide this stuff in macros.
It certainly isn't a good idea. Agreed. I wanted to get this puppy
up and running first before such cleanup, since I don't have access
to all the contoller variants out there.
>
> > +#ifndef PCI_DEVICE_ID_INTEL_80960_RP
> > +#define PCI_DEVICE_ID_INTEL_80960_RP 0x1960
> > +#endif
>
> please update include/linux/pci_ids.h too when PCI ids are missing from
> there. PCI_DEVICE_ID_INTEL_80960_RP at least is not listed there.
Agreed.
> > -static spinlock_t serial_lock = SPIN_LOCK_UNLOCKED;
> > +volatile static spinlock_t serial_lock;
>
> Why do you need to mark this volatile??
>
> BUG: You still need the SPIN_LOCK_UNLOCKED because I don't see an
> associated spin_lock_init in your path.
OK.
> > +static int mega_driver_ioctl (mega_host_config * megaCfg, Scsi_Cmnd * SCpnt)
> > +{
> > + unsigned char *data = (unsigned char *)SCpnt->request_buffer;
>
> cast not necessary. request_buffer is a void.
Agreed.
> > @@ -820,7 +925,7 @@
> >mailbox = (mega_mailbox *) & pScb->mboxData;
> >memset (mailbox, 0, sizeof (pScb->mboxData));
> >
> > - if (data[0] == 0x03) { /* passthrough command */
> > + if (data[0] == 0x03) {/* passthrough command */
> > unsigned char cdblen = data[2];
> > pthru = &pScb->pthru;
> > memset (pthru, 0, sizeof (mega_passthru));
>
> this file is beginning to look like it needs a CodingStyle reformat.
> -after- the fixes and such have been applied, you might consider running
> 'indent' on this puppy.
Agreed - it needs it really badly. Apparently it was originally written
by someone who does ts=2 or some other such mess...
>
> > + switch (data[0])
> > + {
> > + case FW_FIRE_WRITE:
> > + case FW_FIRE_FLASH:
> > +printk("megaraid:Write/ Flash called\n");
> > +if ((ulong)user_area & (PAGE_SIZE - 1)) {
> > + printk("megaraid:user address not aligned on 4K boundary.Error.\n");
> > + SCpnt->result = (DID_ERROR << 16);
> > + callDone (SCpnt);
> > + return NULL;
> > +}
> > +break;
> > + case DCMD_FC_CMD:
> > +mega_build_user_sg(user_area, xfer_size, pScb, mbox);
> > +break;
> >}
> > - copy_from_user(kern_area,user_area,xfer_size);
> > - pScb->kern_area = kern_area;
>
> What happened to copy_from_user? mega_build_user_sg is called with
> user_area as an arg, and it never calls copy_from_user or similar
> functions.
>
> (I understand if this is a bug fix to remove copy_from_user, but I just
> want to make sure it is intentional...)
>
> > + TRACE (("ISR called reentrantly!!\n"));
> > + printk ("ISR called reentrantly!!\n");
>
> All printks need KERN_xxx prefix
Agreed.
>
> >else {
> > -printk(KERN_ERR "megaraid: wrong cmd id completed from
>firmware:id=%x\n",sIdx);
> > +printk("megaraid: wrong cmd id completed from firmware:id=%x\n",sIdx);
>
> hmmm
>
> >/* Copy mailbox data into host structure */
> >megaCfg->mbox64->xferSegment = 0;
> > - memcpy (mbox, mboxData, 16);
> > + memcpy ((char *)mbox, mboxData, 16);
>
> wrong. memcpy takes a void* as its first arg, so no need for a cast.
OK...
> > + while (mbox->numstatus == 0xFF);
> > + while (mbox->status == 0xFF);
> > + while (mbox->mraid_poll != 0x77);
>
> don't you need barriers or something here?
>
> >megaCfg->mbox = &megaCfg->mailbox64.mailbox;
> > - megaCfg->mbox = (mega_mailbox *) u32) megaCfg->mbox) + 16) & 0xfff0);
> > +#ifdef __LP64__
> > + megaCfg->mbox = (mega_mailbox *) u64) megaCfg->mbox) + 16) & ( (ulong)(-1)
>^ 0x0F) );
> >megaCfg->mbox64 = (mega_mailbox64 *) (megaCfg->mbox - 4);
> > - paddr = (paddr + 4 + 16) & 0xfff0;
> > + paddr = (paddr + 4 + 16) & ( (u64)(-1) ^ 0x0F );
> > +#else
> > + megaCfg->mbox = (mega_mailbox *) u32) megaCfg->mbox) + 16) & 0xFFF0);
> > + megaCfg->mbox64 = (mega_mailbox64 *) (megaCfg->mbox - 4);
> > + paddr = (paddr + 4 + 16) & 0xFFF0;
> > +#endif
>
> h
Re: BTTV detection broken in 2.4.0-test11-pre5
On Sun, 19 Nov 2000, Alexander Viro wrote: > > >Kernel on writeprotected floppy disk... > Cute. And when (not if) we get hit by new bug in the net/*/* you will drive > to the location of said router to upgrade the thing. No, post/email a floppy to tech who swaps the floppy and reboots router. -Dan - 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: BTTV detection broken in 2.4.0-test11-pre5
On Sun, 19 Nov 2000, Christer Weinigel wrote: > In article <[EMAIL PROTECTED]> you write: > >On Sun, 19 Nov 2000, Alexander Viro wrote: > >> On Sun, 19 Nov 2000, David Lang wrote: > >> > there is a rootkit kernel module out there that, if loaded onto your > >> > system, can make it almost impossible to detect that your system has been > >> > compramised. with module support disabled this isn't possible. > >> Yes, it is. Easily. If you've got root you can modify the kernel image and > >> reboot the bloody thing. And no, marking it immutable will not help. Open > >> the raw device and modify relevant blocks. > >Kernel on writeprotected floppy disk... > So change the CMOS-settings so that the BIOS changes the boot order > from A, C, CD-ROM to C first instead. *grin* How long do you want > to keep playing Tic-Tac-Toe? Writeprotect the flashbios with the motherboard jumper, and remove the cmos battery. Checkmate. :-) -Dan - 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/
