* Re: FW: Fastest possible UDMA - how?
From: Michael Knigge @ 2003-01-10 19:31 UTC (permalink / raw)
To: Alan Cox; +Cc: Manish Lachwani, Linux Kernel Mailing List
In-Reply-To: <1042229748.32431.13.camel@irongate.swansea.linux.org.uk>
> Not always true. There are a wide number of cases where the
> UDMA mode being used is not the highest one the drive
> or controller supports. The most simple example is if we
> decide the cabling is not suitable for UDMA66 and higher.
Thank you all for your support....
Bye
Michael
^ permalink raw reply
* Re: fb_imageblit()
From: James Simmons @ 2003-01-10 19:23 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Geert Uytterhoeven, Linux Frame Buffer Device Development
In-Reply-To: <1041993390.927.38.camel@localhost.localdomain>
> I've thought of that also, packing the data according to the pixel depth.
Actually I was think more along the image depth. The largest the penguin
logo gets is 224 colors. Meaning the largest image.depth is 8 bits per
pixel. I do agree it is messy to pack the logo data. So for say the 16
color logo (4 bpp) putting two pixels worth of data into each byte and
then seperating it out would be time consuming. The only reason I was
thinking this way is because of userland using the cursor means imageblit
is visible to userland.
> a. Prepare logo data so each pixel of data is in directcolor format (if
> we will use the cmap), so depth corresponds to framebuffer depth, and
> data is packed.
The depth doesn't have to be the same as the framebuffer depth. The logo
data is in terms of color map indices. I did think in terms of packed data
tho.
> d. Get each color component from the cmap data.
>
> e. Recreate pixel data based on var.[color].offset and
> var.[color].length.
Yuck no. Doing a fb_set_cmap should handle that before we call
xxxfb_imageblit. Then xxxfb_imageblit only has to take the data in
the logo data as indices of the color map. Of
> f. Write the pixel data in packed form to the framebuffer.
> Whereas, with the current approach:
>
> a. Prepare logo data such that each pixel corresponds to one byte.
>
> b. Pass the structure to cfb_imageblit.
>
> c. Read color information from pseudopalette if directcolor/truecolor.
>
> d. Write the pixel data in packed form to the framebuffer.
I was think the same way except for the idea of more than one color
indices per byte for less than 8 bpp modes.
> Secondly, indexing the cmap instead of the pseudo_palette means that
> cfb_imageblit has to know the native framebuffer format.
No indexing the cmap. Instead call fb_set_cmap before we call
xxxfb_imageblit. Personally I think we should call fb_set_cmap always.
> I would rather have everything refer to
> the pseudopalette, regardless of the visual format. This will be better
> especially for some of the corner cases, like monochrome cards with
> bits_per_pixel = 8.
It works pretty good for for any pack pixel type modes. Now for planar
cards this isn't the case. Ideally struct fb_cmap should have contained
a
unsigned long pixel;
field. Like X does. It does not and changing that would break things :-(
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: 2.5.54 - quota support
From: Jan Kara @ 2003-01-10 19:32 UTC (permalink / raw)
To: Lukas Hejtmanek; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20030108012133.GA725@mail.muni.cz>
[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]
> On Tue, Jan 07, 2003 at 05:40:28PM +0100, Jan Kara wrote:
> > Reporting 'No such device' was actually bug which was introduced some
> > time ago but nobody probably noticed it... It was introduce when quota
> > code was converted from device numbers to 'bdev' structures.
> > I also fixed one bug in quotaon() call however I'm not sure wheter it
> > could cause the freeze. Anyway patch is attached, try it and tell me
> > about the changes.
>
> Hmm, quotaon / with init=/bin/sh seems to work OK, quota accounting is made and
> repquota displays normal info.
>
> However with normal startup quotaon / still freezes :-(
Ok. So I found the bug. Fix was a bit nontrivial (at one path we tried
to acquire one lock twice) but know it should work. The patch also
contain fix in ext2 - at some time ext2_setattr was written and call of
DQUOT_TRANSFER was missing so no quota was being transferred.
Please test whether the patch works for you.
Honza
PS: First patch is the one I already sent you.
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
[-- Attachment #2: quota-2.5.54-1-lockfix.diff --]
[-- Type: text/plain, Size: 1723 bytes --]
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54/fs/dquot.c linux-2.5.54-1-lockfix/fs/dquot.c
--- linux-2.5.54/fs/dquot.c Mon Jan 6 21:54:10 2003
+++ linux-2.5.54-1-lockfix/fs/dquot.c Thu Jan 9 10:10:55 2003
@@ -1157,6 +1157,7 @@
struct quota_info *dqopt = sb_dqopt(sb);
struct quota_format_type *fmt = find_quota_format(format_id);
int error;
+ unsigned int oldflags;
if (!fmt)
return -ESRCH;
@@ -1181,10 +1182,11 @@
error = -EBUSY;
goto out_lock;
}
+ oldflags = inode->i_flags;
dqopt->files[type] = f;
error = -EINVAL;
if (!fmt->qf_ops->check_quota_file(sb, type))
- goto out_lock;
+ goto out_file_init;
/* We don't want quota on quota files */
dquot_drop_nolock(inode);
inode->i_flags |= S_NOQUOTA;
@@ -1194,7 +1196,7 @@
down(&dqopt->dqio_sem);
if ((error = dqopt->ops[type]->read_file_info(sb, type)) < 0) {
up(&dqopt->dqio_sem);
- goto out_lock;
+ goto out_file_init;
}
up(&dqopt->dqio_sem);
set_enable_flags(dqopt, type);
@@ -1204,9 +1206,10 @@
up_write(&dqopt->dqoff_sem);
return 0;
-out_lock:
- inode->i_flags &= ~S_NOQUOTA;
+out_file_init:
+ inode->i_flags = oldflags;
dqopt->files[type] = NULL;
+out_lock:
up_write(&dqopt->dqoff_sem);
out_f:
filp_close(f, NULL);
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54/fs/quota.c linux-2.5.54-1-lockfix/fs/quota.c
--- linux-2.5.54/fs/quota.c Tue Jan 7 00:47:58 2003
+++ linux-2.5.54-1-lockfix/fs/quota.c Thu Jan 9 10:11:15 2003
@@ -114,7 +114,11 @@
ret = user_path_walk(path, &nd);
if (ret)
goto out;
-
+ ret = bd_acquire(nd.dentry->d_inode);
+ if (ret) {
+ path_release(&nd);
+ goto out;
+ }
bdev = nd.dentry->d_inode->i_bdev;
mode = nd.dentry->d_inode->i_mode;
path_release(&nd);
[-- Attachment #3: quota-2.5.54-2-offsem.diff --]
[-- Type: text/plain, Size: 12420 bytes --]
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54-1-lockfix/fs/dquot.c linux-2.5.54-2-offsem/fs/dquot.c
--- linux-2.5.54-1-lockfix/fs/dquot.c Thu Jan 9 10:10:55 2003
+++ linux-2.5.54-2-offsem/fs/dquot.c Fri Jan 10 01:08:57 2003
@@ -159,7 +159,7 @@
* Note that any operation which operates on dquot data (ie. dq_dqb) must
* hold dq_data_lock.
*
- * Any operation working with dquots must hold dqoff_sem. If operation is
+ * Any operation working with dquots must hold dqptr_sem. If operation is
* just reading pointers from inodes than read lock is enough. If pointers
* are altered function must hold write lock.
*
@@ -270,7 +270,7 @@
}
/* Invalidate all dquots on the list. Note that this function is called after
- * quota is disabled so no new quota might be created. Because we hold dqoff_sem
+ * quota is disabled so no new quota might be created. Because we hold dqptr_sem
* for writing and pointers were already removed from inodes we actually know that
* no quota for this sb+type should be held. */
static void invalidate_dquots(struct super_block *sb, int type)
@@ -287,7 +287,7 @@
if (dquot->dq_type != type)
continue;
#ifdef __DQUOT_PARANOIA
- /* There should be no users of quota - we hold dqoff_sem for writing */
+ /* There should be no users of quota - we hold dqptr_sem for writing */
if (atomic_read(&dquot->dq_count))
BUG();
#endif
@@ -307,7 +307,7 @@
struct quota_info *dqopt = sb_dqopt(sb);
int cnt;
- down_read(&dqopt->dqoff_sem);
+ down_read(&dqopt->dqptr_sem);
restart:
/* At this point any dirty dquot will definitely be written so we can clear
dirty flag from info */
@@ -340,7 +340,7 @@
spin_lock(&dq_list_lock);
dqstats.syncs++;
spin_unlock(&dq_list_lock);
- up_read(&dqopt->dqoff_sem);
+ up_read(&dqopt->dqptr_sem);
return 0;
}
@@ -427,7 +427,7 @@
/*
* Put reference to dquot
* NOTE: If you change this function please check whether dqput_blocks() works right...
- * MUST be called with dqoff_sem held
+ * MUST be called with dqptr_sem held
*/
static void dqput(struct dquot *dquot)
{
@@ -492,7 +492,7 @@
/*
* Get reference to dquot
- * MUST be called with dqoff_sem held
+ * MUST be called with dqptr_sem held
*/
static struct dquot *dqget(struct super_block *sb, unsigned int id, int type)
{
@@ -553,7 +553,7 @@
return 0;
}
-/* This routine is guarded by dqoff_sem semaphore */
+/* This routine is guarded by dqptr_sem semaphore */
static void add_dquot_ref(struct super_block *sb, int type)
{
struct list_head *p;
@@ -586,7 +586,7 @@
}
/* Remove references to dquots from inode - add dquot to list for freeing if needed */
-/* We can't race with anybody because we hold dqoff_sem for writing... */
+/* We can't race with anybody because we hold dqptr_sem for writing... */
int remove_inode_dquot_ref(struct inode *inode, int type, struct list_head *tofree_head)
{
struct dquot *dquot = inode->i_dquot[type];
@@ -829,10 +829,10 @@
unsigned int id = 0;
int cnt;
- down_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
- /* Having dqoff lock we know NOQUOTA flags can't be altered... */
+ down_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
+ /* Having dqptr_sem we know NOQUOTA flags can't be altered... */
if (IS_NOQUOTA(inode)) {
- up_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
return;
}
/* Build list of quotas to initialize... */
@@ -853,7 +853,7 @@
inode->i_flags |= S_QUOTA;
}
}
- up_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
}
/*
@@ -876,9 +876,9 @@
void dquot_drop(struct inode *inode)
{
- down_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ down_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
dquot_drop_nolock(inode);
- up_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
}
/*
@@ -892,7 +892,7 @@
for (cnt = 0; cnt < MAXQUOTAS; cnt++)
warntype[cnt] = NOWARN;
- down_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ down_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
spin_lock(&dq_data_lock);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (inode->i_dquot[cnt] == NODQUOT)
@@ -910,7 +910,7 @@
warn_put_all:
spin_unlock(&dq_data_lock);
flush_warnings(inode->i_dquot, warntype);
- up_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
return ret;
}
@@ -924,7 +924,7 @@
for (cnt = 0; cnt < MAXQUOTAS; cnt++)
warntype[cnt] = NOWARN;
- down_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ down_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
spin_lock(&dq_data_lock);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (inode->i_dquot[cnt] == NODQUOT)
@@ -942,7 +942,7 @@
warn_put_all:
spin_unlock(&dq_data_lock);
flush_warnings((struct dquot **)inode->i_dquot, warntype);
- up_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
return ret;
}
@@ -953,7 +953,7 @@
{
unsigned int cnt;
- down_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ down_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
spin_lock(&dq_data_lock);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (inode->i_dquot[cnt] == NODQUOT)
@@ -962,7 +962,7 @@
}
inode_sub_bytes(inode, number);
spin_unlock(&dq_data_lock);
- up_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
}
/*
@@ -972,7 +972,7 @@
{
unsigned int cnt;
- down_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ down_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
spin_lock(&dq_data_lock);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (inode->i_dquot[cnt] == NODQUOT)
@@ -980,7 +980,7 @@
dquot_decr_inodes(inode->i_dquot[cnt], number);
}
spin_unlock(&dq_data_lock);
- up_read(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
}
/*
@@ -1002,7 +1002,7 @@
transfer_to[cnt] = transfer_from[cnt] = NODQUOT;
warntype[cnt] = NOWARN;
}
- down_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ down_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
if (IS_NOQUOTA(inode)) /* File without quota accounting? */
goto warn_put_all;
/* First build the transfer_to list - here we can block on reading of dquots... */
@@ -1058,7 +1058,7 @@
for (cnt = 0; cnt < MAXQUOTAS; cnt++)
if (transfer_from[cnt] != NODQUOT)
dqput(transfer_from[cnt]);
- up_write(&sb_dqopt(inode->i_sb)->dqoff_sem);
+ up_write(&sb_dqopt(inode->i_sb)->dqptr_sem);
return ret;
}
@@ -1114,7 +1114,8 @@
goto out;
/* We need to serialize quota_off() for device */
- down_write(&dqopt->dqoff_sem);
+ down(&dqopt->dqonoff_sem);
+ down_write(&dqopt->dqptr_sem);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (type != -1 && cnt != type)
continue;
@@ -1145,7 +1146,8 @@
dqopt->info[cnt].dqi_bgrace = 0;
dqopt->ops[cnt] = NULL;
}
- up_write(&dqopt->dqoff_sem);
+ up_write(&dqopt->dqptr_sem);
+ up(&dqopt->dqonoff_sem);
out:
return 0;
}
@@ -1177,7 +1179,8 @@
if (!S_ISREG(inode->i_mode))
goto out_f;
- down_write(&dqopt->dqoff_sem);
+ down(&dqopt->dqonoff_sem);
+ down_write(&dqopt->dqptr_sem);
if (sb_has_quota_enabled(sb, type)) {
error = -EBUSY;
goto out_lock;
@@ -1200,17 +1203,19 @@
}
up(&dqopt->dqio_sem);
set_enable_flags(dqopt, type);
+ up_write(&dqopt->dqptr_sem);
add_dquot_ref(sb, type);
+ up(&dqopt->dqonoff_sem);
- up_write(&dqopt->dqoff_sem);
return 0;
out_file_init:
inode->i_flags = oldflags;
dqopt->files[type] = NULL;
out_lock:
- up_write(&dqopt->dqoff_sem);
+ up_write(&dqopt->dqptr_sem);
+ up(&dqopt->dqonoff_sem);
out_f:
filp_close(f, NULL);
out_fmt:
@@ -1241,14 +1246,14 @@
{
struct dquot *dquot;
- down_read(&sb_dqopt(sb)->dqoff_sem);
+ down_read(&sb_dqopt(sb)->dqptr_sem);
if (!(dquot = dqget(sb, id, type))) {
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return -ESRCH;
}
do_get_dqblk(dquot, di);
dqput(dquot);
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return 0;
}
@@ -1310,14 +1315,14 @@
{
struct dquot *dquot;
- down_read(&sb_dqopt(sb)->dqoff_sem);
+ down_read(&sb_dqopt(sb)->dqptr_sem);
if (!(dquot = dqget(sb, id, type))) {
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return -ESRCH;
}
do_set_dqblk(dquot, di);
dqput(dquot);
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return 0;
}
@@ -1326,9 +1331,9 @@
{
struct mem_dqinfo *mi;
- down_read(&sb_dqopt(sb)->dqoff_sem);
+ down_read(&sb_dqopt(sb)->dqptr_sem);
if (!sb_has_quota_enabled(sb, type)) {
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return -ESRCH;
}
mi = sb_dqopt(sb)->info + type;
@@ -1338,7 +1343,7 @@
ii->dqi_flags = mi->dqi_flags & DQF_MASK;
ii->dqi_valid = IIF_ALL;
spin_unlock(&dq_data_lock);
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return 0;
}
@@ -1347,9 +1352,9 @@
{
struct mem_dqinfo *mi;
- down_read(&sb_dqopt(sb)->dqoff_sem);
+ down_read(&sb_dqopt(sb)->dqptr_sem);
if (!sb_has_quota_enabled(sb, type)) {
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return -ESRCH;
}
mi = sb_dqopt(sb)->info + type;
@@ -1362,7 +1367,7 @@
mi->dqi_flags = (mi->dqi_flags & ~DQF_MASK) | (ii->dqi_flags & DQF_MASK);
mark_info_dirty(mi);
spin_unlock(&dq_data_lock);
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return 0;
}
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54-1-lockfix/fs/ext2/inode.c linux-2.5.54-2-offsem/fs/ext2/inode.c
--- linux-2.5.54-1-lockfix/fs/ext2/inode.c Mon Jan 6 21:53:37 2003
+++ linux-2.5.54-2-offsem/fs/ext2/inode.c Fri Jan 10 01:04:02 2003
@@ -1238,6 +1238,12 @@
error = inode_change_ok(inode, iattr);
if (error)
return error;
+ if ((iattr->ia_valid & ATTR_UID && iattr->ia_uid != inode->i_uid) ||
+ (iattr->ia_valid & ATTR_GID && iattr->ia_gid != inode->i_gid)) {
+ error = DQUOT_TRANSFER(inode, iattr) ? -EDQUOT : 0;
+ if (error)
+ return error;
+ }
inode_setattr(inode, iattr);
if (iattr->ia_valid & ATTR_MODE)
error = ext2_acl_chmod(inode);
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54-1-lockfix/fs/quota.c linux-2.5.54-2-offsem/fs/quota.c
--- linux-2.5.54-1-lockfix/fs/quota.c Thu Jan 9 10:11:15 2003
+++ linux-2.5.54-2-offsem/fs/quota.c Thu Jan 9 23:27:24 2003
@@ -156,13 +156,13 @@
case Q_GETFMT: {
__u32 fmt;
- down_read(&sb_dqopt(sb)->dqoff_sem);
+ down_read(&sb_dqopt(sb)->dqptr_sem);
if (!sb_has_quota_enabled(sb, type)) {
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
return -ESRCH;
}
fmt = sb_dqopt(sb)->info[type].dqi_format->qf_fmt_id;
- up_read(&sb_dqopt(sb)->dqoff_sem);
+ up_read(&sb_dqopt(sb)->dqptr_sem);
if (copy_to_user(addr, &fmt, sizeof(fmt)))
return -EFAULT;
return 0;
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54-1-lockfix/fs/super.c linux-2.5.54-2-offsem/fs/super.c
--- linux-2.5.54-1-lockfix/fs/super.c Mon Jan 6 21:54:11 2003
+++ linux-2.5.54-2-offsem/fs/super.c Thu Jan 9 23:26:50 2003
@@ -71,7 +71,8 @@
atomic_set(&s->s_active, 1);
sema_init(&s->s_vfs_rename_sem,1);
sema_init(&s->s_dquot.dqio_sem, 1);
- init_rwsem(&s->s_dquot.dqoff_sem);
+ sema_init(&s->s_dquot.dqonoff_sem, 1);
+ init_rwsem(&s->s_dquot.dqptr_sem);
s->s_maxbytes = MAX_NON_LFS;
s->dq_op = sb_dquot_ops;
s->s_qcop = sb_quotactl_ops;
diff -ruNX /home/jack/.kerndiffexclude linux-2.5.54-1-lockfix/include/linux/quota.h linux-2.5.54-2-offsem/include/linux/quota.h
--- linux-2.5.54-1-lockfix/include/linux/quota.h Mon Jan 6 21:54:13 2003
+++ linux-2.5.54-2-offsem/include/linux/quota.h Thu Jan 9 23:25:05 2003
@@ -280,7 +280,8 @@
struct quota_info {
unsigned int flags; /* Flags for diskquotas on this device */
struct semaphore dqio_sem; /* lock device while I/O in progress */
- struct rw_semaphore dqoff_sem; /* serialize quota_off() and quota_on() on device and ops using quota_info struct, pointers from inode to dquots */
+ struct semaphore dqonoff_sem; /* Serialize quotaon & quotaoff */
+ struct rw_semaphore dqptr_sem; /* serialize ops using quota_info struct, pointers from inode to dquots */
struct file *files[MAXQUOTAS]; /* fp's to quotafiles */
struct mem_dqinfo info[MAXQUOTAS]; /* Information for each quota type */
struct quota_format_ops *ops[MAXQUOTAS]; /* Operations for each type */
^ permalink raw reply
* Re: lifecycle of a packet (OT)
From: tony @ 2003-01-10 19:24 UTC (permalink / raw)
To: Anders Fugmann; +Cc: Oskar Andreasson, netfilter
In-Reply-To: <3E1EFA34.3050700@fugmann.dhs.org>
Quoting Anders Fugmann <afu@fugmann.dhs.org>:
> Btw. Thanks for a great tutorial. Keep up the good work.
Yes, that tutorial really helps, thanks Oskar. I think it should be
given some sort of "Official" status on the netfilter web site, and they
should definately link to yours instead of hosting an old version.
Just a few suggestions for the tutorial (take 'em or leave 'em ;):
General:
- it would be useful if the guide referred to the versions of
iptables/kernel for which it it is known to be valid
Traversing of tables and chains section:
- the version on netfilter.org is old, doesn't link to the original, and
has broken links (the rc.test-iptables.txt script, for example)
- might benefit from mentioning that EST/REL packets don't traverse the
NAT chain, and why
- as a newbie to iptables and the kernel network stack, I find it
easiest to think in context of an actual connection that I can test. As
such, it might benefit from using example connections to illustrate,
such as in my original post, ie:
masq client -> firewall
masq client -> external
firewall -> external
firewall -> firewall (thanks Joel Newkirk!)
Thanks Oskar, Joel, and Anders!
^ permalink raw reply
* [PATCH] [RESEND] RFC 1812 recommended reject codes Was:[ANNOUNCE] Current netfilter/iptables development
From: Jens Hektor @ 2003-01-10 19:26 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20030110130924.GP1353@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
Hi,
I am submitting the patches hoping they are in the correct form
and get into the queue for 2.4.21.
Credits to Maciej Soltysiak who worked on the same problem also.
Best regards, Jens Hektor
--
Jens Hektor, RWTH Aachen, Rechenzentrum, Seffenter Weg 23, 52074 Aachen
Computing Center, Aachen University, network operation & security
mailto:hektor@RZ.RWTH-Aachen.DE, Tel.: +49 241 80 29206, Raum: 2.35
[-- Attachment #2: fix-RFC-1812-ipt_REJECT-kernel.patch --]
[-- Type: text/plain, Size: 860 bytes --]
--- linux-2.4.20/net/ipv4/netfilter/ipt_REJECT.c.orig 2002-11-29 07:03:27.000000000 +0100
+++ linux-2.4.20/net/ipv4/netfilter/ipt_REJECT.c 2002-11-29 07:07:14.000000000 +0100
@@ -308,6 +308,9 @@
case IPT_ICMP_HOST_PROHIBITED:
send_unreach(*pskb, ICMP_HOST_ANO);
break;
+ case IPT_ICMP_ADMIN_PROHIBITED:
+ send_unreach(*pskb, ICMP_PKT_FILTERED);
+ break;
case IPT_TCP_RESET:
send_reset(*pskb, hooknum == NF_IP_LOCAL_IN);
case IPT_ICMP_ECHOREPLY:
--- linux-2.4.20/include/linux/netfilter_ipv4/ipt_REJECT.h.orig 2002-11-29 07:32:28.000000000 +0100
+++ linux-2.4.20/include/linux/netfilter_ipv4/ipt_REJECT.h 2002-11-29 19:42:47.000000000 +0100
@@ -9,7 +9,8 @@
IPT_ICMP_ECHOREPLY,
IPT_ICMP_NET_PROHIBITED,
IPT_ICMP_HOST_PROHIBITED,
- IPT_TCP_RESET
+ IPT_TCP_RESET,
+ IPT_ICMP_ADMIN_PROHIBITED
};
struct ipt_reject_info {
[-- Attachment #3: fix-RFC-1812-ipt_REJECT-kernel.patch.help --]
[-- Type: text/plain, Size: 305 bytes --]
Author: Jens Hektor <hektor@rz.rwth-aachen.de>
Status: Trivial.
Adds the possibility of sending RFC 1812 recommended reject codes
into the kernel code. (ICMP destination unreachable, code 13,
see RFC 1812, p 81)
Backward compatibility with older iptables
versions preserved by appending to the enum.
[-- Attachment #4: fix-RFC-1812-libipt_REJECT.patch --]
[-- Type: text/plain, Size: 2627 bytes --]
--- iptables-1.2.7a/extensions/libipt_REJECT.c.orig 2002-11-29 19:38:01.000000000 +0100
+++ iptables-1.2.7a/extensions/libipt_REJECT.c 2002-12-02 06:51:31.000000000 +0100
@@ -7,6 +7,8 @@
#include <stdlib.h>
#include <getopt.h>
#include <iptables.h>
+#include <linux/version.h>
+#include <sys/utsname.h>
#include <linux/netfilter_ipv4/ip_tables.h>
#include <linux/netfilter_ipv4/ipt_REJECT.h>
@@ -35,9 +37,17 @@
{"icmp-host-prohibited", "host-prohib",
IPT_ICMP_HOST_PROHIBITED, "ICMP host prohibited"},
{"tcp-reset", "tcp-reset",
- IPT_TCP_RESET, "TCP RST packet"}
+ IPT_TCP_RESET, "TCP RST packet"},
+/* #if to fix compiletime compatibility, adjust version to reflect the include of the kernel patch into the main tree */
+#if ((LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,20) && LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0))||LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,99))
+ {"icmp-admin-prohibited", "admin-prohib",
+ IPT_ICMP_ADMIN_PROHIBITED, "ICMP administratively prohibited"}
+#endif
};
+static
+int icmp_admin_prohib_enabled = 0 ;
+
static void
print_reject_types()
{
@@ -46,8 +56,10 @@
printf("Valid reject types:\n");
for (i = 0; i < sizeof(reject_table)/sizeof(struct reject_names); i++) {
- printf(" %-25s\t%s\n", reject_table[i].name, reject_table[i].desc);
- printf(" %-25s\talias\n", reject_table[i].alias);
+ if ((strcmp ( reject_table[i].name, "icmp-admin-prohibited" ) == 0) && icmp_admin_prohib_enabled) {
+ printf(" %-25s\t%s\n", reject_table[i].name, reject_table[i].desc);
+ printf(" %-25s\talias\n", reject_table[i].alias);
+ }
}
printf("\n");
}
@@ -103,8 +115,13 @@
for (i = 0; i < limit; i++) {
if ((strncasecmp(reject_table[i].name, optarg, strlen(optarg)) == 0)
|| (strncasecmp(reject_table[i].alias, optarg, strlen(optarg)) == 0)) {
- reject->with = reject_table[i].with;
- return 1;
+ if (reject_table[i].with==IPT_ICMP_ADMIN_PROHIBITED && !icmp_admin_prohib_enabled) {
+ exit_error(PARAMETER_PROBLEM,
+ "icmp-admin-prohibited not with this kernel version");
+ } else {
+ reject->with = reject_table[i].with;
+ return 1;
+ }
}
}
/* This due to be dropped late in 2.4 pre-release cycle --RR */
@@ -174,5 +191,15 @@
void _init(void)
{
+ struct utsname buf ;
+ int a, b, c ;
+
+ /* This is to fix run-time compatibility with kernels that
+ are not compatible with this version of iptables */
+ uname(&buf);
+ sscanf (buf.release, "%d.%d.%d", &a, &b, &c);
+ if ((a==2 && b==4 && c>=20) || (a==2 && b==5 && c>=99 ))
+ icmp_admin_prohib_enabled = 1;
+
register_target(&reject);
}
[-- Attachment #5: fix-RFC-1812-libipt_REJECT.patch.help --]
[-- Type: text/plain, Size: 512 bytes --]
Author: Jens Hektor <hektor@rz.rwth-aachen.de>
Status: It Works For Me.
This patch adds a new option for --reject-with, namely
"icmp-admin-prohibited" or short "admin-prohib" to enable
RFC 1812 compatible reject codes.
While the actual code to enable this feature is trivial
most of the code in this patch is to preserve backward
compatibility of a new iptables version running or compiling
on an older kernel.
Assumption in this patch is that 2.4.21 and 2.5.99 support
this feature already in the kernel.
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Matthew D. Pitts @ 2003-01-10 19:37 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030110184739.GA1579@werewolf.able.es>
> > They should probably be marked deprecated, and if they don't get a lot
of
> > maintenance, that's fine.
> >
> > Linus
>
> As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the
> opposite edge ?
>
I heartly second this. And would be willing to do it when time permits.
Matthew
^ permalink raw reply
* Re: Re: [PATCH]: image.depth fix to accomodate monochrome cards
From: James Simmons @ 2003-01-10 19:27 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Geert Uytterhoeven, Linux Fbdev development list
In-Reply-To: <1041991742.927.12.camel@localhost.localdomain>
> I think we still have several corner cases, such as TRUECOLOR with bpp
> <= 8, I'm not sure if that works.
The matorx millenium has such a mode. So such things do exist.
> - if (image->depth == 1) {
> + if (image->depth == 0) {
P.S
I'm just not to crazy about the depth equal zero thing. I just pitcure
developers having a hard time with it.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Rage128 as secondary adapter
From: James Simmons @ 2003-01-10 19:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: Stefan Reinauer, fbdev
In-Reply-To: <20030109185642.33243.qmail@web14914.mail.yahoo.com>
> I doubt if the procedure for resetting the board is
> considered a trade secret. The problem is in getting
> ATIs attention long enough to tell how to do it. It
> may be as simple as poking an output port with a
> special value. Hopefully someone with a manual can
> tell me.
Actually they are funny about it. We have asked before for this info. The
good news is they are starting to lighten up about that. I have code to
boot old Mach 64 cards without a BIOS. I haven't had time to fix it tho.
So it is a matter of time before they will release this info.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [Linux-fbdev-devel] rotation.
From: James Simmons @ 2003-01-10 19:42 UTC (permalink / raw)
To: Antonino Daplas
Cc: Linux Fbdev development list, Linux Kernel Mailing List,
Geert Uytterhoeven
In-Reply-To: <1042171520.933.126.camel@localhost.localdomain>
> > Yes. Hardware rotation shouldn't also not effect the way accel
> > operatations are done.
>
> The main difference is if the hardware supports rotation, fbcon will
> present it with "normal" data. With the generic implementation, fbcon
> will present the driver with rotated data.
>
> So we need a driver capabilities field either in fb_info or
> fb_fix_screeninfo.
We can just test if the rotation hook exist for the fbdev driver. No hook
then use generic code in fbcon. Also we have a angle field in var so we
can see if the user wants the data rotated.
> Not really. We can dynamically rotate the fontdata using the default
> display->fontdata into another buffer. I believe I have functions that
> do that in the patch I submitted. (Sorry, I lost it when one of my
> drives crashed :-(.
I have that patch. It just has to be updated to the latest changes.
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Daniel Ritz @ 2003-01-10 19:44 UTC (permalink / raw)
To: Robert Love; +Cc: Hugh Dickins, William Lee Irwin III, Andi Kleen, linux-kernel
In-Reply-To: <1042218917.722.15.camel@phantasy>
hmm...i don't see why i want wchan. tell me.
but you're right, for some reason linus merged it. so i think (if it's
kept) we should restrict it a bit and make the kallsyms_lookup a bit
faster. not a super fast complex algorithm, but at least not that
braindead as it currently is...
btw. does my ugly early-in-the-moring-hack work right?
On Fri, 2003-01-10 at 18:15, Robert Love wrote:
> On Fri, 2003-01-10 at 11:34, Hugh Dickins wrote:
>
> > Indeed! I think that was Andi volunteering :-}
> > But we should let rml defend his wchan.
>
> Well, of course I want to keep it - but I am biased :)
>
> I think its a simple export that gives us a neat feature. Additionally,
> from the procps perspective, it saves us from having to parse System.map
> for each process. In fact, it means we do not need a System.map at all
> for any procps functionality.
>
> I guess Linus at least mildly liked it too, since he merged it.
>
> But if its such a performance crippling item perhaps it does need to be
> removed (or somehow restricted).
>
> I do agree that, if possible, wchan should be kept simple... so, is
> everyone else for the removal of /proc/pid/wchan ? :-(
>
> Robert Love
>
^ permalink raw reply
* Linux 2.4.21-pre3-ac3 oops with himem
From: Michael Madore @ 2003-01-10 19:45 UTC (permalink / raw)
To: linux-kernel
I received the following oops while running the Cerberus stress test on
2.4.21-pre3-ac3. The hardware is an ASUS A7N8X single AMD Athlon XP
motherboard with the Nvidia nforce2 chipset. The oops occurs as soon as
the system has used all the RAM and tries to use swap. The total amount
of memory on the machine is 1GB, and himem is enabled. If I turn off
himem support the kernel starts to use swap without oopsing. I can
provide my kernel .config or more hardware details if that would be useful.
Mike
ksymoops 2.4.4 on i686 2.4.21-pre3-ac2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-pre3-ac2/ (default)
-m /boot/System.map-2.4.21-pre3-ac2 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address 00000004
c01354e2
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01354e2>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: c197d960 ecx: f71da000 edx: f71da05c
esi: c197d960 edi: 00000000 ebp: 00003737 esp: f71dbdd0
ds: 0018 es: 0018 ss: 0018
Process cp (pid: 1690, stackpage=f71db000)
Stack: c01415f2 f7e84400 c197d960 000001d2 c013f67f 00000000 c197d960
00000000
c197d960 00000020 00003737 c0134ad7 00000004 f71da000 00000200
000001d2
c02fabe8 f71da000 00000000 00000000 00000000 00000020 000001d2
00000006
Call Trace: [<c01415f2>] [<c013f67f>] [<c0134ad7>] [<c0134c70>]
[<c0134cec>]
[<c01357d0>] [<c0135a8b>] [<c012d216>] [<c012d8f5>] [<c012dc5f>]
[<c0150a9c>]
[<c012e14a>] [<c012dfe0>] [<c013cf65>] [<c0108b33>]
Code: 89 58 04 89 03 89 53 04 89 59 5c 89 7b 0c ff 41 68 83 c4 1c
>>EIP; c01354e2 <__free_pages_ok+282/2a0> <=====
Trace; c01415f2 <try_to_free_buffers+d2/160>
Trace; c013f67f <try_to_release_page+2f/50>
Trace; c0134ad7 <shrink_cache+387/3b0>
Trace; c0134c70 <shrink_caches+50/90>
Trace; c0134cec <try_to_free_pages_zone+3c/60>
Trace; c01357d0 <balance_classzone+60/200>
Trace; c0135a8b <__alloc_pages+11b/170>
Trace; c012d216 <page_cache_read+76/d0>
Trace; c012d8f5 <generic_file_readahead+f5/130>
Trace; c012dc5f <do_generic_file_read+2ef/460>
Trace; c0150a9c <dput+1c/160>
Trace; c012e14a <generic_file_read+7a/110>
Trace; c012dfe0 <file_read_actor+0/f0>
Trace; c013cf65 <sys_read+95/110>
Trace; c0108b33 <system_call+33/38>
Code; c01354e2 <__free_pages_ok+282/2a0>
00000000 <_EIP>:
Code; c01354e2 <__free_pages_ok+282/2a0> <=====
0: 89 58 04 mov %ebx,0x4(%eax) <=====
Code; c01354e5 <__free_pages_ok+285/2a0>
3: 89 03 mov %eax,(%ebx)
Code; c01354e7 <__free_pages_ok+287/2a0>
5: 89 53 04 mov %edx,0x4(%ebx)
Code; c01354ea <__free_pages_ok+28a/2a0>
8: 89 59 5c mov %ebx,0x5c(%ecx)
Code; c01354ed <__free_pages_ok+28d/2a0>
b: 89 7b 0c mov %edi,0xc(%ebx)
Code; c01354f0 <__free_pages_ok+290/2a0>
e: ff 41 68 incl 0x68(%ecx)
Code; c01354f3 <__free_pages_ok+293/2a0>
11: 83 c4 1c add $0x1c,%esp
1 warning issued. Results may not be reliable.
^ permalink raw reply
* MTP/AV / Sequencer MIDI problem... design issue?
From: Ryan Pavlik @ 2003-01-10 19:37 UTC (permalink / raw)
To: alsa-devel
Basically, the problem is this. The MTP/AV protocol takes messages
like this:
Dn B1 ... Bn
Where Dn is the device number, and B1..Bn are the midi message bytes.
This, at least, is what I gather from talking to Michael Mayers, the
original driver developer.
You may see the problem now. When multiple threads talk to the device
at once, you have a problem:
A: Dn B1 ,, ,, B2 ...
B: Dn B1 ,, ...
The userland solution, when writing raw midi, is to just put a mutex
on the device and never write an incomplete message.
That is, of course, not an acceptable solution, and it also doesn't
work when you're using the ALSA sequencer interface (at least from the
API calls I've seen). Fixing it in the driver requires interpreting
much MIDI, possibly buffering, and has some problems (what if someone
writes an incomplete message and dies?).
I'd like to hear recommendations; I have a particular interest in
seeing this work and am more than willing to submit patches.
--
Ryan Pavlik <rpav@users.sf.net>
"Hey! Captain talks-too-much, quiet time is now."
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: lifecycle of a packet (OT)
From: Tony Clayton @ 2003-01-10 19:37 UTC (permalink / raw)
To: Anders Fugmann; +Cc: Oskar Andreasson, netfilter
In-Reply-To: <3E1EFA34.3050700@fugmann.dhs.org>
Quoting Anders Fugmann <afu@fugmann.dhs.org>:
> Btw. Thanks for a great tutorial. Keep up the good work.
Yes, that tutorial really helps, thanks Oskar. I think it should be
given some sort of "Official" status on the netfilter web site, and they
should definately link to yours instead of hosting an old version.
Just a few suggestions for the tutorial (take 'em or leave 'em ;):
General:
- it would be useful if the guide referred to the versions of
iptables/kernel for which it it is known to be valid
Traversing of tables and chains section:
- the version on netfilter.org is old, doesn't link to the original, and
has broken links (the rc.test-iptables.txt script, for example)
- might benefit from mentioning that EST/REL packets don't traverse the
NAT chain, and why
- as a newbie to iptables and the kernel network stack, I find it
easiest to think in context of an actual connection that I can test. As
such, it might benefit from using example connections to illustrate,
such as in my original post, ie:
masq client -> firewall
masq client -> external
firewall -> external
firewall -> firewall (thanks Joel Newkirk!)
Thanks Oskar, Joel, and Anders!
^ permalink raw reply
* Re: [linux-lvm] pvcreate -- device "/dev/hdc" has a partition table: force check bypass?
From: Donald Gordon @ 2003-01-10 19:39 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20030111135159.6f968ae6.don@dis.org.nz>
On Sat, 11 Jan 2003 13:51:59 +1300 Donald Gordon <don@dis.org.nz> wrote:
> Hi
>
> I'm trying to setup LVM, but have run into trouble:
>
> unibus:~# blockdev --rereadpt /dev/hdc;dmesg|tail -n 1
> /dev/ide/host0/bus1/target0/lun0: unknown partition table
> unibus:~# pvcreate /dev/hdc
> pvcreate -- device "/dev/hdc" has a partition table
I solved the problem by mounting devfs (it was compiled into my kernel,
but not used). The wording about devfs in the LVM HOWTO could do with
some clarification :-)
don
^ permalink raw reply
* Re: clipping
From: James Simmons @ 2003-01-10 19:39 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Antonino Daplas, Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301092242210.8148-100000@vervain.sonytel.be>
> > I thought about this. Originally I did have this function but removed it.
> > WHat do you think Geert?
>
> Yes, that's OK.
>
> But I was most concerned about fb_ops.fb_imageblit(), since clipping impacts
> fb_image.data as well. IIRC, all (most?) current clipping implementations
> modify fb_image.{dx,dy,width,height} only, without updating fb_image.data.
Good point. Of course we could ignore pieces of data in that image instead
of altering the data. Altering the entire data would be expensive.
> > > The other option (which I don't like) is just to check the passed
> > > fb_var_screeninfo in the put_var ioctl against the current console
> > > window size. But this is not foolproof as we will not be sure of the
> > > resulting window size _after_ the fb_set_var() call.
> >
> > Yuck!!! The other way is better.
>
> Well, in between the calls to fb_ops.fb_check_var() and fb_ops.set_par() you
> can still perform that check. But it's indeed ugly.
Altering to the framebuffer via /dev/fb that would effect the tty should
not remain after the final close of /dev/fb. Instead the console should
reset to its previous state before we first opened /dev/fb.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Rage128 as secondary adapter
From: Jon Smirl @ 2003-01-10 19:40 UTC (permalink / raw)
To: James Simmons; +Cc: Stefan Reinauer, fbdev
In-Reply-To: <Pine.LNX.4.44.0301101930030.18287-100000@phoenix.infradead.org>
--- James Simmons <jsimmons@infradead.org> wrote:
> So it is a matter of time before they will release
> this info.
>
If you can get me the info, I will do the work. I own
both Rage and Radeon cards so I can do some testing.
I'll also add DDC support if they'll give me that
info.
I spent last night disassembling their ROMs. The reset
procedure is not too difficult. But I would much
rather do it with support from ATI documentation. It
is easy to misinterpret a disassembly.
Do you have a personal contact there? Maybe they can
be convinced to publicly release documentation for
their older products. I'm sure NVidia doesn't care how
the Rage chip works any more. It would make a good PR
release about ATI being a community citizen. It would
also free their developer relations group from
hassling with open source developers on older cards.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: fb_imageblit()
From: Geert Uytterhoeven @ 2003-01-10 19:41 UTC (permalink / raw)
To: James Simmons; +Cc: Antonino Daplas, Linux Frame Buffer Device Development
In-Reply-To: <Pine.LNX.4.44.0301101857310.18287-100000@phoenix.infradead.org>
On Fri, 10 Jan 2003, James Simmons wrote:
> > Secondly, indexing the cmap instead of the pseudo_palette means that
> > cfb_imageblit has to know the native framebuffer format.
>
> No indexing the cmap. Instead call fb_set_cmap before we call
> xxxfb_imageblit. Personally I think we should call fb_set_cmap always.
>
> > I would rather have everything refer to
> > the pseudopalette, regardless of the visual format. This will be better
> > especially for some of the corner cases, like monochrome cards with
> > bits_per_pixel = 8.
>
> It works pretty good for for any pack pixel type modes. Now for planar
> cards this isn't the case. Ideally struct fb_cmap should have contained
What do you mean? I don't see a problem for planar modes. A pixel is still a
value of size n bits, it's just that the n bits are not located next to each
other, but spread across multiple words. planar_imageblit() will take care of
converting from chunky to planar mode.
BTW, I do have a working amifb now (it's in Linux/m68k CVS), but the
imageblit() needs more optimizations.
> a
>
> unsigned long pixel;
>
> field. Like X does. It does not and changing that would break things :-(
And let the fbdev driver fill in the pixel values, based on the fb_cmap?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* LCD scaling type
From: Benjamin Herrenschmidt @ 2003-01-10 19:42 UTC (permalink / raw)
To: Linux Fbdev development list
Hi !
When setting a mode on an LCD display that is not exactly the
native mode of that display, we can, on some chips, setup a
scaler. However, most of the time, we have 2 difference choices
for setting up this scaler: It can preserve or not preserve
the aspect ratio. A typical example is the titnium powerbook's 1152x768
mode. If I set it to 1024x768, I can get either horizontal scaling (not
preserving aspect ratio) or no scaling with black bars on left & right
(preserving aspect ratio).
While in most case you actually want to preserve the aspect ratio, it
would still I beleive make sense to let the user choose it.
Could we define one of the reserved fields in fb_var_screeninfo as
beeing a "flags" field for such things ? There are a couple of other
things that we may want to stuff into such a bitfield later, I'd suggest
reserving one 32 bits field for such flags.
Ben.
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: Jeff Garzik @ 2003-01-10 19:51 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel
In-Reply-To: <20030110184739.GA1579@werewolf.able.es>
On Fri, Jan 10, 2003 at 07:47:39PM +0100, J.A. Magallon wrote:
> As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the
> opposite edge ?
CONFIG_OBSOLETE already exists for this.
^ permalink raw reply
* Re: rotation.
From: James Simmons @ 2003-01-10 19:42 UTC (permalink / raw)
To: Antonino Daplas
Cc: Linux Fbdev development list, Linux Kernel Mailing List,
Geert Uytterhoeven
In-Reply-To: <1042171520.933.126.camel@localhost.localdomain>
> > Yes. Hardware rotation shouldn't also not effect the way accel
> > operatations are done.
>
> The main difference is if the hardware supports rotation, fbcon will
> present it with "normal" data. With the generic implementation, fbcon
> will present the driver with rotated data.
>
> So we need a driver capabilities field either in fb_info or
> fb_fix_screeninfo.
We can just test if the rotation hook exist for the fbdev driver. No hook
then use generic code in fbcon. Also we have a angle field in var so we
can see if the user wants the data rotated.
> Not really. We can dynamically rotate the fontdata using the default
> display->fontdata into another buffer. I believe I have functions that
> do that in the patch I submitted. (Sorry, I lost it when one of my
> drives crashed :-(.
I have that patch. It just has to be updated to the latest changes.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Re: [PATCH]: image.depth fix to accomodate monochrome cards
From: Geert Uytterhoeven @ 2003-01-10 19:43 UTC (permalink / raw)
To: James Simmons; +Cc: Antonino Daplas, Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0301101925110.18287-100000@phoenix.infradead.org>
On Fri, 10 Jan 2003, James Simmons wrote:
> > I think we still have several corner cases, such as TRUECOLOR with bpp
> > <= 8, I'm not sure if that works.
>
> The matorx millenium has such a mode. So such things do exist.
>
> > - if (image->depth == 1) {
> > + if (image->depth == 0) {
>
> P.S
>
> I'm just not to crazy about the depth equal zero thing. I just pitcure
> developers having a hard time with it.
Monochrome color expansion just works differently: it expands the zeroes and
ones in a bitmap based on fg_color and bg_color, while image drawing draws an
image containing colormap indices to the frame buffer.
Do you have a better suggestion?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Linux 2.4.21-pre3-ac3 oops with himem
From: Michael Madore @ 2003-01-10 19:56 UTC (permalink / raw)
To: linux-kernel
> I received the following oops while running the Cerberus stress test
on 2.4.21-pre3-ac3. The hardware is an ASUS A7N8X single AMD Athlon XP
> motherboard with the Nvidia nforce2 chipset. The oops occurs as soon
as the system has used all the RAM and tries to use swap. The total
amount of
> memory on the machine is 1GB, and himem is enabled. If I turn off
himem support the kernel starts to use swap without oopsing. I can
provide my
> kernel .config or more hardware details if that would be useful.
Sorry for a little misinformation. I seem to get the oops with himem
disabled as well. I must have just been lucky the first time.
Mike
^ permalink raw reply
* PrintScreen
From: Jan Willem Stumpel @ 2003-01-10 19:49 UTC (permalink / raw)
To: linux-msdos
Pressing the PrtSc key in dosemu (1.1.4.0) prints the (text)
screen, which is a nice surprise.
However, it seems that in my system PrtSc always prints to the
"lp" printer. I would like it to print to another printer I
defined (with a different lpd filter, using the "PC" character set
to print the box characters correctly).
Specifying a different printer in dosemu.conf works for "normal"
DOS printing (printing from applications and COPYing to LPT1), but
not for PrtSc: the printer always seems to be "lp". Can anyone
confirm this? Is there a fix?
Regards, Jan
^ permalink raw reply
* Re: clipping
From: Geert Uytterhoeven @ 2003-01-10 19:48 UTC (permalink / raw)
To: James Simmons; +Cc: Antonino Daplas, Linux Frame Buffer Device Development
In-Reply-To: <Pine.LNX.4.44.0301101936110.18287-100000@phoenix.infradead.org>
On Fri, 10 Jan 2003, James Simmons wrote:
> > > I thought about this. Originally I did have this function but removed it.
> > > WHat do you think Geert?
> >
> > Yes, that's OK.
> >
> > But I was most concerned about fb_ops.fb_imageblit(), since clipping impacts
> > fb_image.data as well. IIRC, all (most?) current clipping implementations
> > modify fb_image.{dx,dy,width,height} only, without updating fb_image.data.
>
> Good point. Of course we could ignore pieces of data in that image instead
> of altering the data. Altering the entire data would be expensive.
Actually I thought about modifying the fb_image.data pointer only. But indeed,
for monochrome expansion you may have to modify the data, since pixel
boundaries in a bitmap don't correspond to byte boundaries.
Alternatively, if fb_image would countain sx and sy fields (cfr. fb_copyarea),
we can just alter (a copy of) sx and sy when clipping.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* NGPT 2.2.0 RELEASED: TOPS LINUXTHREADS AND NPTL IN SCALABILITY AND PERFORMANCE
From: Bill Abt @ 2003-01-10 19:58 UTC (permalink / raw)
To: ibmltc-list, ibm-linux-announce, ibm-linux-dev, ibm-linux-tech,
ltc, pthreads-announce, pthreads-core, pthreads-devel,
pthreads-users
Cc: phil-list, linux-kernel
NGPT - Next Generation POSIX Threading
NGPT Release 2.2.0, released today, 10 January 2003, is the next release
of the "Next Generation"
of Linux pthreads support. This release is fully suitable as a replacement
for LinuxThreads by either
a single user or group or an entire distribution.
In this release, the primary focus was performance. Significant
performance and scalability enhance-
ments have been made to this release making it the fastest and most
scalable POSIX compliant
threads package available on the Linux platform.
In this release, performance and scalability were the key focus of NGPT
developers. Performance and scalability were improved to the point where
NGPT bests both LinuxThreads and the new NPTL threading package in
benchmarks. No changes were made to the kernel patches and thanks to the
NPTL effort, all changes required to run NGPT on the latest 2.5.x kernels
are already included.
Performance and scalability were measured using a benchmark program
developed by Sun Microsystems to "prove" that a 1:1 threading model is
better than the M:N threading model. As can be seen in the benchmark
results NGPT is the performance and scalability leader on both a 2-way and
4-way machine running this benchmark. The benchmark results can be found
on the NGPT website. The benchmark itself can be downloaded from the Sun
Microsystems site.
The NGPT website can be found at
http://www-126.ibm.com/developerworks/opensource/pthreads.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.