Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389
On Mon, Mar 21, 2005 at 06:27:33PM -0800, Andrew Morton wrote: > OK, well unless someone has objections I'll just send all these > > swsusp-add-missing-refrigerator-calls.patch > suspend-to-ram-update-videotxt-with-more-systems.patch > pm-remove-obsolete-pm_-from-vtc.patch > swsusp-small-updates.patch > swsusp-1-1-kill-swsusp_restore.patch > fix-pm_message_t-in-generic-code.patch > fix-u32-vs-pm_message_t-in-usb.patch > more-pm_message_t-fixes.patch > fix-u32-vs-pm_message_t-confusion-in-oss.patch > fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch > fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch > fix-u32-vs-pm_message_t-confusion-in-mmc.patch > fix-u32-vs-pm_message_t-confusion-in-serials.patch > fix-u32-vs-pm_message_t-in-macintosh.patch > fix-u32-vs-pm_message_t-confusion-in-agp.patch > > to Linus when he reappears and then I'll duck for cover and let you guys > sort it out ;) No objection from me, that's probably the best way for this to get into the tree. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Voodoo 3 2000 framebuffer problem
Hi all :) Linux Kernel 2.4.29, in a do-it-yourself linux box, equipped with an AGP Voodoo 3 2000 card, tdfx framebuffer support. I boot in vga mode 0x0f05, with parameter 'video=tdfx:[EMAIL PROTECTED]' and I get (correctly) 100x37 character grid. All of that is correct. What is not correct is the characters attributes, namely the 'blink' attribute. If I use the tdfx framebuffer (I've tested some more resolutions), I lose the blinking text (which I use, for example, for marking my dangling symlinks in 'ls' or 'zsh'). Is this a bug, a feature or just a mistake I'm consistently making? In addition to this, at boot time the background in the lines around the cute penguin logo is white and not black as it should... Thanks a lot in advance. Feel free to ask for more details, tests, etc. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.dervishd.net & http://www.pleyades.net/ It's my PC and I'll cry if I want to... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Short sleep precision
Hello,
>> > You can spin on the gettimeofday() result in userspace.
>> How can I use it?
> Something like:
>
> gettimeofday(,0);
> add_usecs(, time_to_sleep);
> do {
> gettimeofday(,0);
> } while (time_before(, );
That's looks like a lot of CPU consumption, which I would like to avoid
because time_to_sleep is nondeterministic in my case.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mouse with 2.6.10+
On Mon, Mar 21, 2005 at 05:24:11PM -0800, Andrew Morton wrote: > > Any chance the order of module loading changed between the two versions? > > I see you have 'psmouse' as a module. If i8042 (and psmouse) are loaded > > after uhci-hcd (or ohci-hcd), the problem will disappear, too. > > > > > So is this a bios/mobo problem, > > > > Yes. > > > > > or can it be solved in kernel somehow? > > > > We could have usb-handoff by default. > > Did we decide to do that? If so, will it be in 2.6.12? Not yet. There was opposition from Alan Cox, who said that it crashes some machines hard. On the other hand, that is a BIOS interaction bug that most likely can be fixed and is very rare. I'd prefer a 'usb-no-handoff' switch for these machines. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4: Alps touchpad too slow
On Mon, Mar 21, 2005 at 10:25:14PM -0800, Andrew Morton wrote:
> > With cvsbk rev 423b66b6oJOGN68OhmSrBFxxLOtIEA (rsynced Monday, it claims
> > to be "2.6.12-rc1"), the situation is much improved. The AlpsPS/2
> > driver recognizes the trackpad, tracking speed is back to normal, and
> > tapping is turned on by default. (Drat, now I need to figure out how to
> > turn that off again.)
Setting "MaxTapTime" in XF86Config if you're using the Synaptics X
driver, or mousedev.maxtaptime=0 if you are using /dev/input.mice, to 0
should work.
> Wonderful, thanks.
>
> > The kernel output is a bit odd, though:
> >
> > [ 1200.254707] Adding 987988k swap on /dev/hda3. Priority:-1 extents:1
> > [ 1200.330453] EXT3 FS on hda2, internal journal
> > [ 1203.504154] SCSI subsystem initialized
> > [ 1204.039053] Enabling hardware tapping
> > [ 1204.099034] ieee1394: Initialized config rom entry `ip1394'
> > [ 1204.266077] input: PS/2 Mouse on isa0060/serio1
> > [ 1204.400583] input: AlpsPS/2 ALPS GlidePoint on isa0060/serio1
> > [ 1204.779799] sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]>
> > [ 1206.183165] kjournald starting. Commit interval 5 seconds
> >
> > Note how the "Enabling hardware tapping" message is several lines
> > earlier than it seems it should be... I don't think I'm supposed to be
> > tapping on my SCSI hardware.
> >
> > ... ah, I think I'm missing the "ALPS GlidePoint detected" message which
> > I used to get. Without it, the "Enabling hardware tapping" message is a
> > bit opaque.
>
> Yes, alps_init() had a printk removed and now the output looks funny.
I think just removing the message is better.
> diff -puN drivers/input/mouse/alps.c~alps-printk-tidy
> drivers/input/mouse/alps.c
> --- 25/drivers/input/mouse/alps.c~alps-printk-tidy2005-03-21
> 22:23:46.0 -0800
> +++ 25-akpm/drivers/input/mouse/alps.c2005-03-21 22:23:53.0
> -0800
> @@ -395,7 +395,7 @@ int alps_init(struct psmouse *psmouse)
> }
>
> if (param[0] & 0x04) {
> - printk(KERN_INFO " Enabling hardware tapping\n");
> + printk(KERN_INFO "alps.c: Enabling hardware tapping\n");
> if (alps_tap_mode(psmouse, 1))
> printk(KERN_WARNING "alps.c: Failed to enable hardware
> tapping\n");
> }
> _
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] Lifebook: dmi on x86 only
On Tuesday 22 March 2005 02:29, Dave Jones wrote: > On Tue, Mar 22, 2005 at 02:14:55AM -0500, Dmitry Torokhov wrote: > > === > > > > Input: lifebook - DMI facility is only available on i386, do not > >attempt to compile on anything else. > > Why would you want to build a driver for an x86 laptop on anything > but x86 ?Ie, why not just add a dependancy in the Kconfig > so you don't have to add ifdefs to the code ? > lifebook is a part of psmouse driver and is presenty not selectable on its own. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fusion-MPT much faster as module
Hello everyone,
On Mon, 2005-03-21 at 15:27 -0800, Andrew Morton wrote:
> > On a four CPU Opteron compiling the Fusion-MPT as module gives much better
> > performance when compiling it in, here some bonnie++ results:
> >
> > Version 1.03 --Sequential Output-- --Sequential Input-
> > --Random-
> > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> > --Seeks--
> > MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec
> > %CP
> > compiled in 15872M 38366 71 65602 22 18348 4 53276 84 57947 7 905.4
> > 2
> > module 15872M 51246 96 204914 70 57236 14 59779 96 264171 33 923.0
> > 2
> >
> > This happens with 2.6.10, 2.6.11 and 2.6.11-bk2. Controller is a
> > Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI.
> >
> > Why is there such a large difference?
> >
>
> Holger, this problem remains unresolved, does it not? Have you done any
> more experimentation?
Quick summary:
- older IBM xSeries 335 + kernel 2.4.26 = surprisingly slow
- older IBM xSeries 335 + kernel 2.6.8 = pretty fast
- newer IBM xSeries 335 + kernel 2.6.9 = pretty fast
- newer IBM xSeries 335 (and a 336) + kernel 2.6.10 = surprisingly slow
Longer story:
I'm administering bunch of IBM xSeries 335 servers (and one 336, too),
all equipped with the exactly same SCSI controller than in the case
above. In every server Fusion MPT module is compiled straight into
kernel and disk setup is two identical SCSI hard drives in RAID-1 mode.
For the 2.6.x servers about the same kernel .config file is used.
One of the older servers (still using kernel 2.6.8) with P4 Xeon 2.0 GHz
and ~70 GB U320 SCSI disk gives me pretty good results:
---
hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 136 MB in 3.02 seconds = 45.01 MB/sec
---
Identical hardware, but with kernel 2.4.25:
---
hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 64 MB in 3.35 seconds = 19.10 MB/sec
---
A newer generation of x335 (using kernel 2.6.9) with dual P4 Xeon 3.0
GHz and ~70 GB U320 SCSI disk:
---
hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 130 MB in 3.07 seconds = 42.35 MB/sec
---
Still a bit newer generation of x335 with P4 Xeon 3.06 GHz and ~140 GB
U320 SCSI disk, using kernel 2.6.10 is a big disappoitment:
---
hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 48 MB in 3.11 seconds = 15.43 MB/sec
---
And the latest x336 with dual P4 Xeon 3.2 GHz (using kernel 2.6.10) with
~140 GB U320 SCSI disk is also very disappointing:
---
hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 58 MB in 3.02 seconds = 19.20 MB/sec
---
Some info about the oldest x335:
---
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
Fusion MPT SCSI Host driver 3.01.09
scsi0 : ioc0: LSI53C1030, FwRev=01000e00h, Ports=1, MaxQ=222, IRQ=177
Vendor: LSILOGIC Model: 1030 IM Rev: 1000
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 143372288 512-byte hdwr sectors (73407 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Vendor: IBM Model: 25P3495a S320 1 Rev: 1
Type: Processor ANSI SCSI revision: 02
---
A bit newer x335 with kernel 2.6.9:
---
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
Fusion MPT SCSI Host driver 3.01.16
scsi0 : ioc0: LSI53C1030, FwRev=01000e00h, Ports=1, MaxQ=222, IRQ=22
Vendor: LSILOGIC Model: 1030 IM Rev: 1000
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 143372288 512-byte hdwr sectors (73407 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Vendor: IBM Model: 25P3495a S320 1 Rev: 1
Type: Processor ANSI SCSI revision: 02
Attached scsi generic sg1 at scsi0, channel 0, id 8, lun 0, type 3
---
And the latest x335 we have:
---
Fusion MPT base driver 3.01.18
Copyright (c) 1999-2004 LSI Logic Corporation
ACPI: PCI interrupt :01:01.0[A] -> GSI 22 (level, low) -> IRQ 169
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
Fusion MPT SCSI Host driver 3.01.18
scsi0 : ioc0: LSI53C1030, FwRev=01032316h, Ports=1, MaxQ=222, IRQ=169
Vendor: LSILOGIC Model: 1030 IM Rev: 1000
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 286746624 512-byte hdwr sectors (146814 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 286746624 512-byte hdwr sectors (146814 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 >
Attached scsi
Re: [PATCH 1/4] Lifebook: dmi on x86 only
On Tue, Mar 22, 2005 at 02:14:55AM -0500, Dmitry Torokhov wrote: > === > > Input: lifebook - DMI facility is only available on i386, do not >attempt to compile on anything else. Why would you want to build a driver for an x86 laptop on anything but x86 ?Ie, why not just add a dependancy in the Kconfig so you don't have to add ifdefs to the code ? Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-01
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > it includes the latest round of RCU fixes - but doesnt solve the SMP
> > bootup crash.
>
> Hello, Ingo,
>
> Does the following help with the SMP problem? This fix and the
> earlier one make my old patch survive a few rounds of kernbench on a
> 4-CPU x86 box. [...]
does not seem to fix my testbox (see the crash log below). I've uploaded
the 40-02 patch with both of your fixes (maybe i mismerged something
somewhere). Does it boot on your box with PREEMPT_RT enabled? The patch
order is:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.41-02
Ingo
NET: Registered protocol family 16
BUG: Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
c0131bcc
*pde =
Oops: 0002 [#1]
PREEMPT SMP
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010297 (2.6.12-rc1-RT-V0.7.41-01)
EIP is at rcu_advance_callbacks+0x3c/0x80
eax: ebx: c050f280 ecx: c12191e0 edx:
esi: c1341c64 edi: c1341be4 ebp: c1355dd0 esp: c1355dc8
ds: 007b es: 007b ss: 0068 preempt: 0003
Process khelper (pid: 17, threadinfo=c1354000 task=c13538d0)
Stack: 0001 c12191e0 c1355de4 c0131c47 0001 c1341bdc c13004d8 c1355e00
c017e529 c1341bdc c04d6e80 c1358006 fffe c1355e54 c1355e70 c0174aac
c1341bdc c1355e50 c1355e4c c1355e54 c1358001 c1341bdc c04cf920 0286
Call Trace:
[] show_stack+0x7f/0xa0 (28)
[] show_registers+0x16a/0x1e0 (56)
[] die+0x101/0x190 (64)
[] do_page_fault+0x442/0x680 (216)
[] error_code+0x2b/0x30 (68)
[] call_rcu+0x37/0x70 (20)
[] dput+0x139/0x210 (28)
[] __link_path_walk+0x9fc/0xf80 (112)
[] link_path_walk+0x4a/0x130 (100)
[] path_lookup+0x9e/0x1c0 (32)
[] open_exec+0x28/0x100 (100)
[] do_execve+0x44/0x220 (36)
[] sys_execve+0x42/0xa0 (36)
[] syscall_call+0x7/0xb (-8096)
---
| preempt count: 0004 ]
| 4-level deep critical section nesting:
.. [] call_rcu+0x1f/0x70
.[] .. ( <= dput+0x139/0x210)
.. [] rcu_advance_callbacks+0x13/0x80
.[] .. ( <= call_rcu+0x37/0x70)
.. [] _raw_spin_lock_irqsave+0x1a/0xa0
.[] .. ( <= die+0x3f/0x190)
.. [] print_traces+0x16/0x50
.[] .. ( <= show_stack+0x7f/0xa0)
Code: 00 00 e8 78 2d 0a 00 8b 0c 85 20 20 51 c0 bb 80 f2 50 c0 01 d9 f0 83 44
24 00 00 a1 88 19 52 c0 39 41 40 74 23 8b 41 44 8b 51 50 <89> 02 8b 41 48 c7 41
44 00 00 00 00 89 41 50 8d 41 44 89 41 48
(gdb) list *0xc0131bcc
0xc0131bcc is in rcu_advance_callbacks (kernel/rcupdate.c:586).
581 struct rcu_data *rdp;
582
583 rdp = _cpu_var(rcu_data);
584 smp_mb(); /* prevent sampling batch # before list
removal. */
585 if (rdp->batch != rcu_ctrlblk.batch) {
586 *rdp->donetail = rdp->waitlist;
587 rdp->donetail = rdp->waittail;
588 rdp->waitlist = NULL;
589 rdp->waittail = >waitlist;
590 rdp->batch = rcu_ctrlblk.batch;
(gdb)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 > the journalling job also? Ext2 does not do journaling. Ext3 does. >> Perhaps squashfs is good enough improvement over cramfs... But I'd >> like those 4Gb limits to go away. >> > we all do - but who does really care about stupid 4Gb limits on embedded > systems with e.g. > 8 or 32 Mb maybe more of Flash Ram? really noboby Then if this filesystem is specifically targeted ONLY on embedded then that's reason for keeping it out-of-tree. > if you want to have a squashfs for DVD images e.g. not 4.7Gb but > DualLayer ect., why do you complain? > you are maybe not even - nor you will be - a user of squashfs. but there But if a filesystem COULD be made to work for MORE users - why not? I'm sure that more than a few might use it in some form if such a limit is removed - why lock us into a corner that when we do get around to fixing it we need a new on-disk format and then we might have a new filesystem, squashfs2 or whatever. > are many people outside that use > squashfs on different platforms and want to have it integrated to > mainline kernel. so why are you blocking? I think that's because people see a potential in it that has a flaw that should be taken care of so that MORE people can use it, and not ONLY "embedded people with 8 or 32 MB". Seriously, noone's flaming here - I think what people want is for a limit to be removed, and that is not in my eyes a bad thing. // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCP8cGBrn2kJu9P78RAsTnAKCfslYF0ez4Wkt5xgKs7AXXp1KlUgCgt0y/ pX+t5HtVhQ+EvIo667XaDBA= =Q6RX -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] psmouse: dynamic protocol switching via sysfs
===
Input: psmouse - export protocol as a sysfs per-device attribute.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
drivers/input/mouse/psmouse-base.c | 291 ++---
drivers/input/mouse/psmouse.h |1
drivers/input/serio/serio.c| 44 +
include/linux/serio.h |6
4 files changed, 290 insertions(+), 52 deletions(-)
Index: dtor/drivers/input/serio/serio.c
===
--- dtor.orig/drivers/input/serio/serio.c
+++ dtor/drivers/input/serio/serio.c
@@ -43,6 +43,7 @@ MODULE_LICENSE("GPL");
EXPORT_SYMBOL(serio_interrupt);
EXPORT_SYMBOL(__serio_register_port);
EXPORT_SYMBOL(serio_unregister_port);
+EXPORT_SYMBOL(serio_unregister_child_port);
EXPORT_SYMBOL(__serio_unregister_port_delayed);
EXPORT_SYMBOL(__serio_register_driver);
EXPORT_SYMBOL(serio_unregister_driver);
@@ -90,12 +91,19 @@ static void serio_bind_driver(struct ser
down_write(_bus.subsys.rwsem);
if (serio_match_port(drv->id_table, serio)) {
+ /* make sure parent is not about to change */
+ if (serio->parent)
+ down(>parent->drv_sem);
+
serio->dev.driver = >driver;
if (drv->connect(serio, drv)) {
serio->dev.driver = NULL;
goto out;
}
device_bind_driver(>dev);
+
+ if (serio->parent)
+ up(>parent->drv_sem);
}
out:
up_write(_bus.subsys.rwsem);
@@ -150,12 +158,12 @@ static void serio_queue_event(void *obje
spin_lock_irqsave(_event_lock, flags);
/*
-* Scan event list for the other events for the same serio port,
+* Scan event list for the other events for the same serio port,
* starting with the most recent one. If event is the same we
* do not need add new one. If event is of different type we
* need to add this event and should not look further because
* we need to preseve sequence of distinct events.
-*/
+*/
list_for_each_entry_reverse(event, _event_list, node) {
if (event->object == object) {
if (event->type == event_type)
@@ -614,6 +622,19 @@ void serio_unregister_port(struct serio
}
/*
+ * Safely unregisters child port if one is present.
+ */
+void serio_unregister_child_port(struct serio *serio)
+{
+ down(_sem);
+ if (serio->child) {
+ serio_disconnect_port(serio->child);
+ serio_destroy_port(serio->child);
+ }
+ up(_sem);
+}
+
+/*
* Submits register request to kseriod for subsequent execution.
* Can be used when it is not obvious whether the serio_sem is
* taken or not and when delayed execution is feasible.
@@ -669,8 +690,18 @@ static int serio_driver_probe(struct dev
{
struct serio *serio = to_serio_port(dev);
struct serio_driver *drv = to_serio_driver(dev->driver);
+ int result;
+
+ /* make sure parent is not about to change */
+ if (serio->parent)
+ down(>parent->drv_sem);
+
+ result = drv->connect(serio, drv);
+
+ if (serio->parent)
+ up(>parent->drv_sem);
- return drv->connect(serio, drv);
+ return result;
}
static int serio_driver_remove(struct device *dev)
@@ -678,7 +709,14 @@ static int serio_driver_remove(struct de
struct serio *serio = to_serio_port(dev);
struct serio_driver *drv = to_serio_driver(dev->driver);
+ if (serio->parent)
+ down(>parent->drv_sem);
+
drv->disconnect(serio);
+
+ if (serio->parent)
+ up(>parent->drv_sem);
+
return 0;
}
Index: dtor/drivers/input/mouse/psmouse.h
===
--- dtor.orig/drivers/input/mouse/psmouse.h
+++ dtor/drivers/input/mouse/psmouse.h
@@ -78,6 +78,7 @@ enum psmouse_type {
PSMOUSE_SYNAPTICS,
PSMOUSE_ALPS,
PSMOUSE_LIFEBOOK,
+ PSMOUSE_AUTO/* This one should always be last */
};
int psmouse_sliced_command(struct psmouse *psmouse, unsigned char command);
Index: dtor/include/linux/serio.h
===
--- dtor.orig/include/linux/serio.h
+++ dtor/include/linux/serio.h
@@ -83,6 +83,7 @@ static inline void serio_register_port(s
}
void serio_unregister_port(struct serio *serio);
+void serio_unregister_child_port(struct serio *serio);
void __serio_unregister_port_delayed(struct serio *serio, struct module
*owner);
static inline void serio_unregister_port_delayed(struct serio *serio)
{
@@ -153,6 +154,11 @@ static inline int serio_pin_driver(struc
return down_interruptible(>drv_sem);
}
+static inline void serio_pin_driver_uninterruptible(struct
[PATCH 3/4] Lifebook: rearrange init code
===
Input: lifebook - adjust initialization routines to be in line with
the rest of protocols in preparation to dynamic protocol
switching.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
lifebook.c | 46 --
lifebook.h |4 ++--
psmouse-base.c | 14 --
3 files changed, 42 insertions(+), 22 deletions(-)
Index: dtor/drivers/input/mouse/lifebook.h
===
--- dtor.orig/drivers/input/mouse/lifebook.h
+++ dtor/drivers/input/mouse/lifebook.h
@@ -11,7 +11,7 @@
#ifndef _LIFEBOOK_H
#define _LIFEBOOK_H
-int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
-int set_properties);
+int lifebook_detect(struct psmouse *psmouse, int set_properties);
+int lifebook_init(struct psmouse *psmouse);
#endif
Index: dtor/drivers/input/mouse/psmouse-base.c
===
--- dtor.orig/drivers/input/mouse/psmouse-base.c
+++ dtor/drivers/input/mouse/psmouse-base.c
@@ -424,8 +424,18 @@ static int psmouse_extensions(struct psm
{
int synaptics_hardware = 0;
- if (lifebook_detect(psmouse, max_proto, set_properties) == 0)
- return PSMOUSE_LIFEBOOK;
+/*
+ * We always check for lifebook because it does not disturb mouse
+ * (it only checks DMI information).
+ */
+ if (lifebook_detect(psmouse, set_properties) == 0 ||
+ max_proto == PSMOUSE_LIFEBOOK) {
+
+ if (max_proto > PSMOUSE_IMEX) {
+ if (!set_properties || lifebook_init(psmouse) == 0)
+ return PSMOUSE_LIFEBOOK;
+ }
+ }
/*
* Try Kensington ThinkingMouse (we try first, because synaptics probe
Index: dtor/drivers/input/mouse/lifebook.c
===
--- dtor.orig/drivers/input/mouse/lifebook.c
+++ dtor/drivers/input/mouse/lifebook.c
@@ -71,7 +71,7 @@ static psmouse_ret_t lifebook_process_by
return PSMOUSE_FULL_PACKET;
}
-static int lifebook_initialize(struct psmouse *psmouse)
+static int lifebook_absolute_mode(struct psmouse *psmouse)
{
struct ps2dev *ps2dev = >ps2dev;
unsigned char param;
@@ -95,27 +95,37 @@ static void lifebook_disconnect(struct p
psmouse_reset(psmouse);
}
-int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
-int set_properties)
+int lifebook_detect(struct psmouse *psmouse, int set_properties)
{
-if (lifebook_check_dmi() && max_proto != PSMOUSE_LIFEBOOK)
+if (lifebook_check_dmi())
return -1;
if (set_properties) {
- psmouse->vendor = "Fujitsu Lifebook";
- psmouse->name = "TouchScreen";
- psmouse->dev.evbit[0] = BIT(EV_ABS) | BIT(EV_KEY) | BIT(EV_REL);
- psmouse->dev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT) |
BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
- psmouse->dev.keybit[LONG(BTN_TOUCH)] = BIT(BTN_TOUCH);
- psmouse->dev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
- input_set_abs_params(>dev, ABS_X, 0, 1024, 0, 0);
- input_set_abs_params(>dev, ABS_Y, 0, 1024, 0, 0);
-
- psmouse->protocol_handler = lifebook_process_byte;
- psmouse->disconnect = lifebook_disconnect;
- psmouse->reconnect = lifebook_initialize;
- psmouse->pktsize = 3;
+ psmouse->vendor = "Fujitsu";
+ psmouse->name = "Lifebook TouchScreen";
+
}
-return lifebook_initialize(psmouse);
+return 0;
}
+
+int lifebook_init(struct psmouse *psmouse)
+{
+ if (lifebook_absolute_mode(psmouse))
+ return -1;
+
+ psmouse->dev.evbit[0] = BIT(EV_ABS) | BIT(EV_KEY) | BIT(EV_REL);
+ psmouse->dev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) |
BIT(BTN_RIGHT);
+ psmouse->dev.keybit[LONG(BTN_TOUCH)] = BIT(BTN_TOUCH);
+ psmouse->dev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
+ input_set_abs_params(>dev, ABS_X, 0, 1024, 0, 0);
+ input_set_abs_params(>dev, ABS_Y, 0, 1024, 0, 0);
+
+ psmouse->protocol_handler = lifebook_process_byte;
+ psmouse->disconnect = lifebook_disconnect;
+ psmouse->reconnect = lifebook_absolute_mode;
+ psmouse->pktsize = 3;
+
+ return 0;
+}
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Lifebook: various cleanups
===
Input: lifebook - various cleanups:
- do not try to set rate and resolution in init method, let
psmouse core do it for us. This also removes special quirks
from the core;
- do not disable mouse before doing full reset - meaningless;
- some formatting and whitespace cleanups.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
lifebook.c | 31 ++-
lifebook.h |2 +-
psmouse-base.c |2 --
3 files changed, 11 insertions(+), 24 deletions(-)
Index: dtor/drivers/input/mouse/lifebook.h
===
--- dtor.orig/drivers/input/mouse/lifebook.h
+++ dtor/drivers/input/mouse/lifebook.h
@@ -11,7 +11,7 @@
#ifndef _LIFEBOOK_H
#define _LIFEBOOK_H
-int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
+int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
int set_properties);
#endif
Index: dtor/drivers/input/mouse/psmouse-base.c
===
--- dtor.orig/drivers/input/mouse/psmouse-base.c
+++ dtor/drivers/input/mouse/psmouse-base.c
@@ -579,8 +579,6 @@ static void psmouse_set_rate(struct psmo
static void psmouse_initialize(struct psmouse *psmouse)
{
-if (psmouse->type==PSMOUSE_LIFEBOOK)
-return;
/*
* We set the mouse into streaming mode.
*/
Index: dtor/drivers/input/mouse/lifebook.c
===
--- dtor.orig/drivers/input/mouse/lifebook.c
+++ dtor/drivers/input/mouse/lifebook.c
@@ -19,8 +19,6 @@
#include "psmouse.h"
#include "lifebook.h"
-static int max_y = 1024;
-
#if defined(__i386__)
#include
static struct dmi_system_id lifebook_dmi_table[] = {
@@ -46,7 +44,7 @@ static psmouse_ret_t lifebook_process_by
unsigned char *packet = psmouse->packet;
struct input_dev *dev = >dev;
- if ( psmouse->pktcnt != 3 )
+ if (psmouse->pktcnt != 3)
return PSMOUSE_GOOD_DATA;
input_regs(dev, regs);
@@ -56,12 +54,12 @@ static psmouse_ret_t lifebook_process_by
input_report_abs(dev, ABS_X,
(packet[1] | ((packet[0] & 0x30) << 4)));
input_report_abs(dev, ABS_Y,
-max_y - (packet[2] | ((packet[0] & 0xC0) <<
2)));
+1024 - (packet[2] | ((packet[0] & 0xC0) <<
2)));
} else {
- input_report_rel(dev, REL_X,
- ((packet[0] & 0x10) ? packet[1]-256 :
packet[1]));
- input_report_rel(dev, REL_Y,
- (- (int)((packet[0] & 0x20) ? packet[2]-256 :
packet[2])));
+ input_report_rel(dev, REL_X,
+ ((packet[0] & 0x10) ? packet[1] - 256 :
packet[1]));
+ input_report_rel(dev, REL_Y,
+-(int)((packet[0] & 0x20) ? packet[2] - 256 :
packet[2]));
}
input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
@@ -78,26 +76,17 @@ static int lifebook_initialize(struct ps
struct ps2dev *ps2dev = >ps2dev;
unsigned char param;
- if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
- return -1;
-
- if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+ if (psmouse_reset(psmouse))
return -1;
- /*
+ /*
Enable absolute output -- ps2_command fails always but if
you leave this call out the touchsreen will never send
absolute coordinates
- */
+ */
param = 0x07;
ps2_command(ps2dev, , PSMOUSE_CMD_SETRES);
- psmouse->set_rate(psmouse, psmouse->rate);
- psmouse->set_resolution(psmouse, psmouse->resolution);
-
- if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE))
- return -1;
-
return 0;
}
@@ -106,7 +95,7 @@ static void lifebook_disconnect(struct p
psmouse_reset(psmouse);
}
-int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
+int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
int set_properties)
{
if (lifebook_check_dmi() && max_proto != PSMOUSE_LIFEBOOK)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver
On Monday 21 March 2005 10:31, Kenan Esau wrote: > Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov: > > > > There are couple of things that I an concerned with: > > > > 1. I don't like that it overrides meaning of max_proto parameter to be > > exactly the protocol specified. > > Yeah -- I agree. I also don't like that double-meaning. That was the > reason why I originally proposed the use of a new parameter... > Ok, I have some patches to lifebook that I would like to included (if they work): 1. lifebook-dmi-x86-only - do not compile in DMI detection on anything but x86. 2. lifebook-cleanup - do not set rate/resolution nor enable the device in lifebook initialization routines, let psmouse code do it for us. 3. lifebook-init - rearrange initialization code to be more like other protocols to ease dynamic protocol switching. 4. psmouse-proto-attr - expose protocol as a sysfs attribute and allow changing it from userspace. Please give it a try and let me know if it does/does not work. Thanks! -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Lifebook: dmi on x86 only
===
Input: lifebook - DMI facility is only available on i386, do not
attempt to compile on anything else.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
lifebook.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
Index: dtor/drivers/input/mouse/lifebook.c
===
--- dtor.orig/drivers/input/mouse/lifebook.c
+++ dtor/drivers/input/mouse/lifebook.c
@@ -15,17 +15,17 @@
#include
#include
#include
-#include
#include "psmouse.h"
#include "lifebook.h"
static int max_y = 1024;
-
+#if defined(__i386__)
+#include
static struct dmi_system_id lifebook_dmi_table[] = {
{
- .ident = "Fujitsu Siemens Lifebook B-Sereis",
+ .ident = "Lifebook",
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
},
@@ -33,6 +33,13 @@ static struct dmi_system_id lifebook_dmi
{ }
};
+static inline int lifebook_check_dmi(void)
+{
+return dmi_check_system(lifebook_dmi_table) ? 0 : -1;
+}
+#else
+static inline int lifebook_check_dmi(void) { return -1; }
+#endif
static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct
pt_regs *regs)
{
@@ -102,8 +109,7 @@ static void lifebook_disconnect(struct p
int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto,
int set_properties)
{
-if (!dmi_check_system(lifebook_dmi_table) &&
-(max_proto != PSMOUSE_LIFEBOOK) )
+if (lifebook_check_dmi() && max_proto != PSMOUSE_LIFEBOOK)
return -1;
if (set_properties) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Support for GEODE CPUs
Kianusch Sayah Karadji <[EMAIL PROTECTED]> wrote:
>
> On Mon, 21 Mar 2005, Andrew Morton wrote:
>
> >> Either revert it or make it Geode GX and correct the options set. I've
> >> no problem with a Geode option that sets the right options 8)
> >
> > Two weeks, no patch. It looks like we'll be reverting it.
>
> I somehow missed the thread in the list discussing the neccesary changes.
>
> Anyway here's a new patch (this time for 2.6.11).
>
> I changed the whole thing from "Geode GX" to "Geode GX1", and made the
> adjustments Alan suggested.
The original patch was already applied, so I made an incremental update.
Please double-check it.
Sometime, could you send me a little description of what the patch does
("the adjustments Alan suggested") so Linus knows what we're doing to his
kernel? And a Signed-off-by: line too, please.
diff -puN arch/i386/Kconfig~x86-geode-support-fixes arch/i386/Kconfig
--- 25/arch/i386/Kconfig~x86-geode-support-fixes2005-03-21
23:09:34.0 -0800
+++ 25-akpm/arch/i386/Kconfig 2005-03-21 23:09:53.0 -0800
@@ -187,7 +187,7 @@ config M386
- "Winchip-C6" for original IDT Winchip.
- "Winchip-2" for IDT Winchip 2.
- "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
- - "MediaGX/Geode" for Cyrix MediaGX aka Geode.
+ - "GeodeGX1" for Geode GX1 (Cyrix MediaGX).
- "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
- "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
@@ -315,12 +315,10 @@ config MWINCHIP3D
stores for this CPU, which can increase performance of some
operations.
-config MGEODE
- bool "MediaGX/Geode"
+config MGEODEGX1
+ bool "GeodeGX1"
help
- Select this for a Cyrix MediaGX aka Geode chip. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment reqirements.
+ Select this for a Geode GX1 (Cyrix MediaGX) chip.
config MCYRIXIII
bool "CyrixIII/VIA-C3"
@@ -372,7 +370,7 @@ config X86_L1_CACHE_SHIFT
int
default "7" if MPENTIUM4 || X86_GENERIC
default "4" if X86_ELAN || M486 || M386
- default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE ||
MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX
|| M586TSC || M586 || MVIAC3_2 || MGEODE
+ default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE ||
MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX
|| M586TSC || M586 || MVIAC3_2 || MGEODEGX1
default "6" if MK7 || MK8 || MPENTIUMM
config RWSEM_GENERIC_SPINLOCK
@@ -391,7 +389,7 @@ config GENERIC_CALIBRATE_DELAY
config X86_PPRO_FENCE
bool
- depends on M686 || M586MMX || M586TSC || M586 || M486 || M386 || MGEODE
+ depends on M686 || M586MMX || M586TSC || M586 || M486 || M386 ||
MGEODEGX1
default y
config X86_F00F_BUG
@@ -421,7 +419,7 @@ config X86_POPAD_OK
config X86_ALIGNMENT_16
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII ||
X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODE
+ depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII ||
X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1
default y
config X86_GOOD_APIC
@@ -446,7 +444,7 @@ config X86_USE_3DNOW
config X86_OOSTORE
bool
- depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MGEODE) && MTRR
+ depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6) && MTRR
default y
config HPET_TIMER
@@ -582,7 +580,7 @@ config X86_VISWS_APIC
config X86_TSC
bool
- depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON ||
MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII
|| M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MGEODE) && !X86_NUMAQ
+ depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON ||
MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII
|| M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MGEODEGX1) && !X86_NUMAQ
default y
config X86_MCE
diff -puN arch/i386/Makefile~x86-geode-support-fixes arch/i386/Makefile
--- 25/arch/i386/Makefile~x86-geode-support-fixes 2005-03-21
23:09:34.0 -0800
+++ 25-akpm/arch/i386/Makefile 2005-03-21 23:09:53.0 -0800
@@ -14,7 +14,7 @@
# 19990713 Artur Skawina <[EMAIL PROTECTED]>
# Added '-march' and '-mpreferred-stack-boundary' support
#
-# Kianusch Sayah Karadji <[EMAIL PROTECTED]>
+# 20050320 Kianusch Sayah Karadji <[EMAIL PROTECTED]>
# Added support for GEODE CPU
LDFLAGS:= -m elf_i386
@@ -54,8 +54,8 @@ cflags-$(CONFIG_MVIAC3_2) += $(call cc-o
# AMD Elan support
cflags-$(CONFIG_X86_ELAN) += -march=i486
-# MediaGX aka Geode support
-cflags-$(CONFIG_MGEODE)+= $(call
Re: [patch 1/2] fork_connector: add a fork connector
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
> If a bunch of applications are listening for fork events,
> your patch allows any application to turn off the
> fork event notification? Is this the right behavior?
Yes it is. The main management is done by application so, if several
applications are listening for fork events you need to choose which one
will turn off the fork connector.
I want to keep this turn on/off mechanism simple but if it's needed I
can manage the variable "cn_fork_enable" as a counter. Thus the callback
could be something like:
static void cn_fork_callback(void *data)
{
int start;
struct cn_msg *msg = (struct cn_msg *)data;
if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) {
memcpy(, msg->data, sizeof(cn_fork_enable));
if (start)
cn_fork_enable++;
else
cn_fork_enable > 0 ? cn_fork_enable-- : 0;
}
}
What do you think about this implementation?
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: -snip- So we are replacing severely-limited cramfs with also-limited squashfs... I think that's rather unfair, Squashfs is significantly better than cramfs. The main aim of Squashfs has been to achieve the best Yes, it *is* rather unfair. Sorry about that. But having 2 different limited compressed filesystems in kernel does not seem good to me. what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 the journalling job also? is there really a need for cifs and samba and ncpfs and nfs v3 and nfs v4? why? -snip- Well, out-of-tree maintainenance takes lot of time, too, so by keeping limited code out-of-kernel we provide quite good incentive to make those limits go away. Perhaps squashfs is good enough improvement over cramfs... But I'd like those 4Gb limits to go away. Pavel we all do - but who does really care about stupid 4Gb limits on embedded systems with e.g. 8 or 32 Mb maybe more of Flash Ram? really noboby if you want to have a squashfs for DVD images e.g. not 4.7Gb but DualLayer ect., why do you complain? you are maybe not even - nor you will be - a user of squashfs. but there are many people outside that use squashfs on different platforms and want to have it integrated to mainline kernel. so why are you blocking? did you have a look at the code? did you find a "trojan horse"? no and no? so why are you blocking? if the coding style is not that what nowadays kernel coder have as coding style? if you care - fix it - otherwise give hints and other people will do. regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Hi! > Well, probably Phillip can answer this better than me, but the main > differences that affect end users (and that is why we are using > SquashFS right now) are: > CRAMFS SquashFS > > Max File Size 16Mb 4Gb > Max Filesystem Size256Mb 4Gb? > > > >>>So we are replacing severely-limited cramfs with also-limited > >>>squashfs... For live DVDs etc 4Gb filesystem size limit will hurt for > >>>sure, and 4Gb file size limit will hurt, too. Can those be fixed? > >>> > >>> > > > >... > > > > > >>but if there is a contribution from the outside - it is not taken "as is" > >>and maybe fixed up, which > >>should be nearly possible in the same time like analysing and commenting > >>the code - it ends up > >>in having less supported hardware. > >> > >>imho if a hardware company does indeed provide us with opensource > >>drivers, we should take these > >>things as a gift, not as a "not coding guide a'like" intrusion which > >>has to be defeated. > > > >Remember that horse in Troja? It was a gift, too. > of course there had been a horse in troja., but thinking like that > nowadays is a bit incorrect - don't you agree? > > code is reviewed normally - thats what i told before and i stated as > good feature - but there is no serious reason > to blame every code to have potential "trojan horses" inside and to > reject it. I should have added a smiley. I'm not seriously suggesting that it contains deliberate problem. But codestyle uglyness and arbitrary limits may come back and haunt us in future. Once code is in kernel, it is very hard to change on-disk format, for example. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with w6692 & kernel >=2.6.10
On Mon, Mar 21, 2005 at 02:28:23PM -0800, Andrew Morton wrote: > Marko Rebrina <[EMAIL PROTECTED]> wrote: > > > > I have problem with w6692 (mISDN-2005-02-25) & kernel >=2.6.10 (with > > 2.6.9 is OK!) > > There haven't been any changes in the w6692 driver for ages, so I'd be > suspecting PCI changes or something like that. Are you able to test > 2.6.12-rc1? > Marko do not point to the in kernel w6692 driver, but to the (still ALPHA) mISDN driver from cvs.isdn4linux.de. This driver had a problem with the pci_register_driver return code changes in 2.6.10, it now always returns 0 (if no error), but < 2.6.10 did return the number of detected devices, which was tested in this driver. This is fixed since last week in our CVS. -- Karsten Keil SuSE Labs ISDN development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 (stable and -rc) ACPI breaks USB
On Mon, 21 Mar 2005, Andrew Morton wrote: Grzegorz Kulewski <[EMAIL PROTECTED]> wrote: Hi, I just installed 2.6.11 and I was hit by the same bug (or feature?) I found in -rcs. Basically my USB will work only if acpi=off was passed to the kernel. It looks like without acpi=off it will assign IRQ 10 and with acpi=off it will assign IRQ9. It worked at least with 2.6.9. I do not know if the USB is completly broken but at least my speedtouch modem will not work (the red led will be on for some time then completly black). I didn't really follow all the ins and outs on this one. Will it end up being adequately resolved for 2.6.12? It was identified (by Bjorn) to be some ACPI VIA PCI IRQ routing quirk logic change (as far as I understand it). Unfortunatelly it is not good for my board (AMD 761 North and VIA 686B South). Bjorn (huge thanks to him) produced testing patch that fixed it for me. Further patches were presented and discussed in the other thread. The newest one is waiting for final testing from me (in couple of minutes probably). I will CC you on my reply (if you are not already). As of what to do next with this patch (if it still works) Bjorn and others should reply. Thanks. Thanks for interest, Grzegorz Kulewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1
On Mon, 2005-03-21 at 16:42 -0800, Jesse Barnes wrote: > On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote: > > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote: > > > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc > > > >1/2. 6.12-rc1-mm1/ > > > > > > Andrew, please drop > > > > > > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions. > > >patch > > > > > > The tiocx.c driver is now in the tree, and it uses those functions. > > > > IOW: > > The EXPORT_SYMBOL's should still be removed, but the functions > > themselves should stay. > > Actually, no, since tiocx can be built modular. The patch should just be > dropped. ... or changed so that the exports are _GPL ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] freepgt: free_pgtables use vma list
Builds clean and boots on ia64. I haven't tried any hugetlb operations on it though. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4: Alps touchpad too slow
Andy Isaacson <[EMAIL PROTECTED]> wrote: > > My Vaio r505te comes up with an unusably slow touchpad if I allow the > ALPS driver to drive it. It says > > > ALPS Touchpad (Glidepoint) detected > > Disabling hardware tapping > > input: AlpsPS/2 ALPS TouchPad on isa0060/serio1 > > and then the trackpad operates at about 1/8 the speed I've gotten used > to. > > I'm running 2.6.11-rc4; this started happening somewhere between > 2.6.10 and 2.6.11-rc3. > > I've toyed with 'xset m', but nothing I've done there seems to have > any effect. (I suspect that Linux never generates the appropriate > sequence of mouse events to trigger the X cursor acceleration regime.) > > I can restore the original behavior by passing "proto=exps" to > psmouse.o, in which case I get > > input: PS/2 Generic Mouse on isa0060/serio1 > > On a related note, how are users supposed to control this newfangled > PS2 driver? I'd like at least the *option* to turn tapping back on, > but I can't find any knobs *anywhere*. And of course I'd like to > adjust the tracking speed, too. > Andy, could you please test 2.6.12-rc1 and let us know which problems remain? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reduce inlined x86 memcpy by 2 bytes
On Sunday 20 March 2005 15:17, Adrian Bunk wrote:
> Hi Denis,
>
> what do your benchmarks say about replacing the whole assembler code
> with a
>
> #define __memcpy __builtin_memcpy
It generates call to out-of-line memcpy()
if count is non-constant.
# cat t.c
extern char *a, *b;
extern int n;
void f() {
__builtin_memcpy(a,b,n);
}
void g() {
__builtin_memcpy(a,b,24);
}
# gcc -S -O2 --omit-frame-pointer t.c
# cat t.s
.file "t.c"
.text
.p2align 2,,3
.globl f
.type f, @function
f:
subl$16, %esp
pushl n
pushl b
pushl a
callmemcpy
addl$28, %esp
ret
.size f, .-f
.p2align 2,,3
.globl g
.type g, @function
g:
pushl %edi
pushl %esi
movla, %edi
movlb, %esi
cld
movl$6, %ecx
rep
movsl
popl%esi
popl%edi
ret
.size g, .-g
.section.note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.1"
Proving that it is slower than inline is left
as an excercise to the reader :)
Kernel one will be inlined always.
void h) { __memcpy(a,b,n);} is
movln, %eax
pushl %edi
movl%eax, %ecx
pushl %esi
movla, %edi
movlb, %esi
shrl$2, %ecx
#APP
rep ; movsl
movl %eax,%ecx
andl $3,%ecx
jz 1f
rep ; movsb
1:
#NO_APP
popl%esi
popl%edi
ret
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Hi! [I'm not sure if I should further feed the trolls.] > >Yes, it *is* rather unfair. Sorry about that. But having 2 different > >limited compressed filesystems in kernel does not seem good to me. > what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 > the journalling job also? > is there really a need for cifs and samba and ncpfs and nfs v3 and nfs > v4? why? Take a look at debate that preceded xfs merge. And btw reiserfs4 is *not* merged. And people merging xfs/reiserfs4/etc did address problems pointed out in their code. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 40/48] dibusb: HanfTek UMT-010 fixes
HanfTek UMT-010: adapted the pll-programming, the usb-ids and the firmware name
to the new firmware (thanks to Sunny Liu from HanfTek)
(Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvb-dibusb-core.c |8
dvb-dibusb-fe-i2c.c | 49 +++--
dvb-dibusb-usb.c|4 +---
3 files changed, 28 insertions(+), 33 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:18:30.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:27:58.0 +0100
@@ -98,7 +98,7 @@ MODULE_PARM_DESC(rc_key_repeat_count, "h
#define USB_PID_UNK_HYPER_PALTEK_COLD 0x005e
#define USB_PID_UNK_HYPER_PALTEK_WARM 0x005f
#define USB_PID_HANFTEK_UMT_010_COLD 0x0001
-#define USB_PID_HANFTEK_UMT_010_WARM 0x0025
+#define USB_PID_HANFTEK_UMT_010_WARM 0x0015
#define USB_PID_YAKUMO_DTT200U_COLD0x0201
#define USB_PID_YAKUMO_DTT200U_WARM0x0301
#define USB_PID_WINTV_NOVA_T_USB2_COLD 0x9300
@@ -235,9 +235,9 @@ static struct dibusb_device_class dibusb
_tuner[DIBUSB_TUNER_COFDM_PANASONIC_ENV57H1XD5],
},
{ UMT2_0, _usb_ctrl[2],
- "dvb-dibusb-umt-1.fw",
- 0x01, 0x02,
- 7, 188*21,
+ "dvb-dibusb-umt-2.fw",
+ 0x01, 0x06,
+ 20, 512,
DIBUSB_RC_NO,
_demod[DIBUSB_MT352],
_tuner[DIBUSB_TUNER_CABLE_LG_TDTP_E102P],
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
2005-03-22 00:18:55.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
2005-03-22 00:27:58.0 +0100
@@ -345,8 +345,6 @@ static int panasonic_cofdm_env57h1xd5_pl
* BSn = 0 corresponding port is off, high-impedance state (at
power-on)
* BSn = 1 corresponding port is on
*/
-
-
static int panasonic_cofdm_env77h11d5_tda6650_init(struct dvb_frontend *fe, u8
pllbuf[4])
{
pllbuf[0] = 0x0b;
@@ -441,55 +439,54 @@ static int panasonic_cofdm_env77h11d5_td
* 0 1 c2 (always valid)
* 1 0 c4
* 1 1 c6
- *
- *
- *
*/
-
static int lg_tdtp_e102p_tua6034(struct dvb_frontend_parameters* fep, u8
pllbuf[4])
{
u32 div;
- u8 p3210, p4;
+ u8 p210, p3;
#define TUNER_MUL 62500
div = (fep->frequency + 36125000 + TUNER_MUL / 2) / TUNER_MUL;
+// div = ((fep->frequency/1000 + 36166) * 6) / 1000;
if (fep->frequency < 17450)
- p3210 = 1; // not supported by the tdtp_e102p
+ p210 = 1; // not supported by the tdtp_e102p
else if (fep->frequency < 23000) // VHF
- p3210 = 2;
+ p210 = 2;
else
- p3210 = 4;
+ p210 = 4;
if (fep->u.ofdm.bandwidth == BANDWIDTH_7_MHZ)
- p4 = 0;
+ p3 = 0;
else
- p4 = 1;
+ p3 = 1;
pllbuf[0] = (div >> 8) & 0x7f;
pllbuf[1] = div & 0xff;
pllbuf[2] = 0xce;
- pllbuf[3] = (p4 << 4) | p3210;
+// pllbuf[2] = 0xcc;
+ pllbuf[3] = (p3 << 3) | p210;
return 0;
}
static int lg_tdtp_e102p_mt352_demod_init(struct dvb_frontend *fe)
{
- static u8 mt352_clock_config[] = { 0x89, 0xb0, 0x2d };
+ static u8 mt352_clock_config[] = { 0x89, 0xb8, 0x2d };
static u8 mt352_reset[] = { 0x50, 0x80 };
static u8 mt352_mclk_ratio[] = { 0x8b, 0x00 };
static u8 mt352_adc_ctl_1_cfg[] = { 0x8E, 0x40 };
- static u8 mt352_agc_cfg[] = { 0x67, 0x14, 0x22 };
- static u8 mt352_sec_agc_cfg[] = { 0x69, 0x00, 0xff, 0xff, 0x00, 0xff,
0x00, 0x40, 0x40 };
-
- static u8 mt352_unk [] = { 0xb5, 0x7a };
+ static u8 mt352_agc_cfg[] = { 0x67, 0x10, 0xa0 };
- static u8 mt352_acq_ctl[] = { 0x53, 0x5f };
- static u8 mt352_input_freq_1[] = { 0x56, 0xf1, 0x05 };
+ static u8 mt352_sec_agc_cfg1[] = { 0x6a, 0xff };
+ static u8 mt352_sec_agc_cfg2[] = { 0x6d, 0xff };
+ static u8 mt352_sec_agc_cfg3[] = { 0x70, 0x40 };
+ static u8 mt352_sec_agc_cfg4[] = { 0x7b, 0x03 };
+ static u8 mt352_sec_agc_cfg5[] = { 0x7d, 0x0f };
-// static u8 mt352_capt_range_cfg[] = { 0x75, 0x32 };
+ static u8 mt352_acq_ctl[] = { 0x53, 0x50 };
+ static u8 mt352_input_freq_1[] = { 0x56, 0x31, 0x06 };
mt352_write(fe, mt352_clock_config, sizeof(mt352_clock_config));
udelay(2000);
@@ -499,15 +496,15 @@ static int lg_tdtp_e102p_mt352_demod_ini
Re: [PATCH 1/5] freepgt: free_pgtables use vma list
Hugh Dickins wrote:
On Mon, 21 Mar 2005, David S. Miller wrote:
On Tue, 22 Mar 2005 15:14:54 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
Question, Dave: flush_tlb_pgtables after Hugh's patch is also
possibly not being called with enough range to cover all page
tables that have been freed.
Good question from Nick.
For example, you may have a single page (start,end) address range
to free, but if this is enclosed by a large enough (floor,ceiling)
then it may free an entire pgd entry.
I assume the intention of the API would be to provide the full
pgd width in that case?
It just wants the range of page tables liberated. I guess
essentially PMD_SIZE is the granularity.
I _think_ that answer means that my current code is fine in this respect.
But I'm not entirely convinced. Since sparc64 is the only architecture
which implements a flush_tlb_pgtables which actually uses start,end,
we do need to suit your needs there - informed reassurance welcome!
But Hugh I think you may still be freeing pgd (PGDIR_SIZE)
regions that you don't quite cover with flush_tlb_pgtables?
I would have thought you'd need something like this:
if (!tlb_is_full_mm(tlb)) {
/* This is the full range of page tables we could possibly free
*/
start = max(start & PGDIR_SIZE, (floor + PMD_SIZE - 1) &
PMD_SIZE);
end = min((end + PGDIR_SIZE - 1) & PGDIR_SIZE, ceiling &
PMD_SIZE);
flush_tlb_pgtables(tlb->mm, start, end);
}
But I'll have to go away and look at it more...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 26/48] av7110: error handling during attach
Janitoring - error handling during attach
o av7110_arm_sync(): small helper to factor out some code;
o av7110_attach() does not check the status code returned by all the
functions is uses;
o balance the error path in av7110_attach and have it easy to check.
Please check it;
o if everything is correctly balanced, device_initialized is not needed
anymore in struct av7110;
o av7110_detach(): no need to cast a void * pointer;
o av7110_detach(): die #ifdef, die !
o change the returned value of av7110_av_exit() as it can't fail;
o change the returned value of av7110_ca_init() as it can fail. Removed
extraneous casts while are it;
o check for failure of vmalloc() in ci_ll_init().
o vfree(NULL) is safe.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
av7110.c | 194 -
av7110.h |2
av7110_av.c| 25 ---
av7110_av.h|2
av7110_ca.c| 20 -
av7110_ca.h|2
av7110_ipack.c |1
7 files changed, 147 insertions(+), 99 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/av7110.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/ttpci/av7110.c 2005-03-22
00:17:56.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/av7110.c 2005-03-22
00:18:08.0 +0100
@@ -188,6 +188,15 @@ static void arm_error(struct av7110 *av7
recover_arm(av7110);
}
+static void av7110_arm_sync(struct av7110 *av7110)
+{
+ av7110->arm_rmmod = 1;
+ wake_up_interruptible(>arm_wait);
+
+ while (av7110->arm_thread)
+ msleep(1);
+}
+
static int arm_thread(void *data)
{
struct av7110 *av7110 = data;
@@ -1461,6 +1470,11 @@ static int check_firmware(struct av7110*
#ifdef CONFIG_DVB_AV7110_FIRMWARE_FILE
#include "av7110_firm.h"
+static void put_firmware(struct av7110* av7110)
+{
+ av7110->bin_fw = NULL;
+}
+
static inline int get_firmware(struct av7110* av7110)
{
av7110->bin_fw = dvb_ttpci_fw;
@@ -1468,6 +1482,11 @@ static inline int get_firmware(struct av
return check_firmware(av7110);
}
#else
+static void put_firmware(struct av7110* av7110)
+{
+ vfree(av7110->bin_fw);
+}
+
static int get_firmware(struct av7110* av7110)
{
int ret;
@@ -1960,8 +1979,10 @@ static u8 read_pwm(struct av7110* av7110
return pwm;
}
-static void frontend_init(struct av7110 *av7110)
+static int frontend_init(struct av7110 *av7110)
{
+ int ret;
+
if (av7110->dev->pci->subsystem_vendor == 0x110a) {
switch(av7110->dev->pci->subsystem_device) {
case 0x: // Fujitsu/Siemens DVB-Cable (ves1820/Philips
CD1516(??))
@@ -2054,7 +2075,9 @@ static void frontend_init(struct av7110
}
}
- if (av7110->fe == NULL) {
+ if (!av7110->fe) {
+ /* FIXME: propagate the failure code from the lower layers */
+ ret = -ENOMEM;
printk("dvb-ttpci: A frontend driver was not found for device
%04x/%04x subsystem %04x/%04x\n",
av7110->dev->pci->vendor,
av7110->dev->pci->device,
@@ -2071,13 +2094,15 @@ static void frontend_init(struct av7110
FE_FUNC_OVERRIDE(av7110->fe->ops->dishnetwork_send_legacy_command,
av7110->fe_dishnetwork_send_legacy_command,
av7110_fe_dishnetwork_send_legacy_command);
FE_FUNC_OVERRIDE(av7110->fe->ops->set_frontend,
av7110->fe_set_frontend, av7110_fe_set_frontend);
- if (dvb_register_frontend(av7110->dvb_adapter, av7110->fe)) {
+ ret = dvb_register_frontend(av7110->dvb_adapter, av7110->fe);
+ if (ret < 0) {
printk("av7110: Frontend registration failed!\n");
if (av7110->fe->ops->release)
av7110->fe->ops->release(av7110->fe);
av7110->fe = NULL;
}
}
+ return ret;
}
/* Budgetpatch note:
@@ -2147,10 +2172,10 @@ static void frontend_init(struct av7110
*/
static int av7110_attach(struct saa7146_dev* dev, struct
saa7146_pci_extension_data *pci_ext)
{
- struct av7110 *av7110 = NULL;
- int length = TS_WIDTH * TS_HEIGHT;
- int ret = 0;
- int count = 0;
+ const int length = TS_WIDTH * TS_HEIGHT;
+ struct pci_dev *pdev = dev->pci;
+ struct av7110 *av7110;
+ int ret, count = 0;
dprintk(4, "dev: %p\n", dev);
@@ -2244,7 +2269,8 @@ static int av7110_attach(struct saa7146_
}
/* prepare the av7110 device struct */
- if (!(av7110 = kmalloc (sizeof (struct av7110), GFP_KERNEL))) {
+ av7110 = kmalloc(sizeof(struct av7110), GFP_KERNEL);
+ if (!av7110) {
dprintk(1, "out of memory\n");
return -ENOMEM;
[DVB patch 30/48] OREN or51211, or51132_qam and or51132_vsb firmware download info
o add OREN or51211, or51132_qam and or51132_vsb firmware
o correct some links
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
contributors.txt |3 +++
get_dvb_firmware | 50 +-
readme.txt |7 ---
3 files changed, 52 insertions(+), 8 deletions(-)
Index: linux-2.6.12-rc1-mm1/Documentation/dvb/get_dvb_firmware
===
--- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/get_dvb_firmware
2005-03-22 00:18:18.0 +0100
+++ linux-2.6.12-rc1-mm1/Documentation/dvb/get_dvb_firmware 2005-03-22
00:18:42.0 +0100
@@ -22,14 +22,15 @@ use File::Temp qw/ tempdir /;
use IO::Handle;
@components = ( "sp8870", "sp887x", "tda10045", "tda10046", "av7110",
"dec2000t",
- "dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002" );
+ "dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002",
+ "or51211", "or51132_qam", "or51132_vsb");
# Check args
syntax() if (scalar(@ARGV) != 1);
$cid = $ARGV[0];
# Do it!
-for($i=0; $i < scalar(@components); $i++) {
+for ($i=0; $i < scalar(@components); $i++) {
if ($cid eq $components[$i]) {
$outfile = eval($cid);
die $@ if $@;
@@ -122,9 +123,9 @@ sub tda10046 {
}
sub av7110 {
-my $sourcefile = "dvb-ttpci-01.fw-261c";
-my $url = "http://www.linuxtv.org/download/dvb/firmware/$sourcefile;;
-my $hash = "7b263de6b0b92d2347319c65adc7d4fb";
+my $sourcefile = "dvb-ttpci-01.fw-261d";
+my $url = "http://www.linuxtv.org/downloads/firmware/$sourcefile;;
+my $hash = "603431b6259715a8e88f376a53b64e2f";
my $outfile = "dvb-ttpci-01.fw";
checkstandard();
@@ -251,6 +252,45 @@ sub nxt2002 {
$outfile;
}
+sub or51211 {
+my $fwfile = "dvb-fe-or51211.fw";
+my $url = "http://linuxtv.org/downloads/firmware/$fwfile;;
+my $hash = "d830949c771a289505bf9eafc225d491";
+
+checkstandard();
+
+wgetfile($fwfile, $url);
+verify($fwfile, $hash);
+
+$fwfile;
+}
+
+sub or51132_qam {
+my $fwfile = "dvb-fe-or51132-qam.fw";
+my $url = "http://linuxtv.org/downloads/firmware/$fwfile;;
+my $hash = "7702e8938612de46ccadfe9b413cb3b5";
+
+checkstandard();
+
+wgetfile($fwfile, $url);
+verify($fwfile, $hash);
+
+$fwfile;
+}
+
+sub or51132_vsb {
+my $fwfile = "dvb-fe-or51132-vsb.fw";
+my $url = "http://linuxtv.org/downloads/firmware/$fwfile;;
+my $hash = "c16208e02f36fc439a557ad4c613364a";
+
+checkstandard();
+
+wgetfile($fwfile, $url);
+verify($fwfile, $hash);
+
+$fwfile;
+}
+
# ---
# Utilities
Index: linux-2.6.12-rc1-mm1/Documentation/dvb/contributors.txt
===
--- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/contributors.txt
2005-03-21 23:27:57.0 +0100
+++ linux-2.6.12-rc1-mm1/Documentation/dvb/contributors.txt 2005-03-22
00:18:42.0 +0100
@@ -72,5 +72,8 @@ Kenneth Aafløy <[EMAIL PROTECTED]>
Ernst Peinlich <[EMAIL PROTECTED]>
for tuning/DiSEqC support for the DEC 3000-s
+Peter Beutner <[EMAIL PROTECTED]>
+ for the IR code for the ttusb-dec driver
+
(If you think you should be in this list, but you are not, drop a
line to the DVB mailing list)
Index: linux-2.6.12-rc1-mm1/Documentation/dvb/readme.txt
===
--- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/readme.txt 2005-03-21
23:27:57.0 +0100
+++ linux-2.6.12-rc1-mm1/Documentation/dvb/readme.txt 2005-03-22
00:18:42.0 +0100
@@ -5,8 +5,9 @@ The main development site and CVS reposi
drivers is http://linuxtv.org/.
The developer mailing list linux-dvb is also hosted there,
-see http://linuxtv.org/mailinglists.xml. Please check
-the archive http://linuxtv.org/mailinglists/linux-dvb/
+see http://linuxtv.org/lists.php. Please check
+the archive http://linuxtv.org/pipermail/linux-dvb/
+and the Wiki http://linuxtv.org/wiki/
before asking newbie questions on the list.
API documentation, utilities and test/example programs
@@ -15,7 +16,7 @@ are available as part of the old driver
We plan to split this into separate packages, but it's not
been done yet.
-http://linuxtv.org/download/dvb/
+http://linuxtv.org/downloads/
What's inside this directory:
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel bug: futex_wait hang
On Tue, Mar 22, 2005 at 12:30:53AM -0500, Lee Revell wrote: > On Mon, 2005-03-21 at 21:08 -0800, Andrew Morton wrote: > > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > > > > > The most recent messages under "Futex queue_me/get_user ordering", > > > with a patch from Jakub Jelinek will fix this problem by changing the > > > kernel. Yes, you should apply Jakub's most recent patch, message-ID > > > "<[EMAIL PROTECTED]>". > > > > > > I have not tested the patch, but it looks convincing. > > > > OK, thanks. Lee && Paul, that's at > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/broken-out/futex-queue_me-get_user-ordering-fix.patch > > > > Does not fix the problem. Have you analyzed the use of mutexes/condvars in the program? The primary suspect is a deadlock, race of some kind or other bug in the program. All these will show up as a hang in FUTEX_WAIT. The argument that it works with LinuxThreads doesn't count, the timing and internals of both threading libraries are so different that a program bug can only show up with one of the threading libraries and not both. Only once you distill a minimal self-contained testcase that proves the program is correct and it gets analyzed, it is time to talk about NPTL or kernel bugs. Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4: Alps touchpad too slow
Andy Isaacson <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 21, 2005 at 02:44:12PM -0800, Andrew Morton wrote:
> > Andy Isaacson <[EMAIL PROTECTED]> wrote:
> > > My Vaio r505te comes up with an unusably slow touchpad if I allow the
> > > ALPS driver to drive it. It says
> > >
> > > > ALPS Touchpad (Glidepoint) detected
> > > > Disabling hardware tapping
> > > > input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
> > >
> > > and then the trackpad operates at about 1/8 the speed I've gotten used
> > > to. ... 2.6.11-rc4 ...
> >
> > Andy, could you please test 2.6.12-rc1 and let us know which problems
> > remain?
>
> With cvsbk rev 423b66b6oJOGN68OhmSrBFxxLOtIEA (rsynced Monday, it claims
> to be "2.6.12-rc1"), the situation is much improved. The AlpsPS/2
> driver recognizes the trackpad, tracking speed is back to normal, and
> tapping is turned on by default. (Drat, now I need to figure out how to
> turn that off again.)
Wonderful, thanks.
> The kernel output is a bit odd, though:
>
> [ 1200.254707] Adding 987988k swap on /dev/hda3. Priority:-1 extents:1
> [ 1200.330453] EXT3 FS on hda2, internal journal
> [ 1203.504154] SCSI subsystem initialized
> [ 1204.039053] Enabling hardware tapping
> [ 1204.099034] ieee1394: Initialized config rom entry `ip1394'
> [ 1204.266077] input: PS/2 Mouse on isa0060/serio1
> [ 1204.400583] input: AlpsPS/2 ALPS GlidePoint on isa0060/serio1
> [ 1204.779799] sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]>
> [ 1206.183165] kjournald starting. Commit interval 5 seconds
>
> Note how the "Enabling hardware tapping" message is several lines
> earlier than it seems it should be... I don't think I'm supposed to be
> tapping on my SCSI hardware.
>
> ... ah, I think I'm missing the "ALPS GlidePoint detected" message which
> I used to get. Without it, the "Enabling hardware tapping" message is a
> bit opaque.
Yes, alps_init() had a printk removed and now the output looks funny.
diff -puN drivers/input/mouse/alps.c~alps-printk-tidy drivers/input/mouse/alps.c
--- 25/drivers/input/mouse/alps.c~alps-printk-tidy 2005-03-21
22:23:46.0 -0800
+++ 25-akpm/drivers/input/mouse/alps.c 2005-03-21 22:23:53.0 -0800
@@ -395,7 +395,7 @@ int alps_init(struct psmouse *psmouse)
}
if (param[0] & 0x04) {
- printk(KERN_INFO " Enabling hardware tapping\n");
+ printk(KERN_INFO "alps.c: Enabling hardware tapping\n");
if (alps_tap_mode(psmouse, 1))
printk(KERN_WARNING "alps.c: Failed to enable hardware
tapping\n");
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 21/48] refactor sw pid filter to drop redundant code
o added index field to struct dvb_demux_feed for having a unique feed id, which
can be used for hardware pid filter tables
o dibusb: adding the index to struct dvb_demux_feed makes dibusb-pid-filtering
redundant
o ttusb-budget: struct channel removed in favour of dvbdmxfeed->index
(Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dibusb/dvb-dibusb-pid.c | 80
-
linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/Makefile |3
linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c|2
linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c | 24
--
linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb.h | 10 -
linux-2.6.12-rc1-mm1/drivers/media/dvb/dvb-core/dvb_demux.c|4
linux-2.6.12-rc1-mm1/drivers/media/dvb/dvb-core/dvb_demux.h|1
linux-2.6.12-rc1-mm1/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 86
+-
8 files changed, 24 insertions(+), 186 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/Makefile
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/Makefile 2005-03-21
23:27:58.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/Makefile 2005-03-22
00:17:09.0 +0100
@@ -3,8 +3,7 @@ dvb-dibusb-objs = dvb-dibusb-core.o \
dvb-dibusb-fe-i2c.o \
dvb-dibusb-firmware.o \
dvb-dibusb-remote.o \
- dvb-dibusb-usb.o \
- dvb-dibusb-pid.o
+ dvb-dibusb-usb.o
obj-$(CONFIG_DVB_DIBUSB) += dvb-dibusb.o
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:16:28.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:17:09.0 +0100
@@ -349,7 +349,6 @@ static int dibusb_exit(struct usb_dibusb
dibusb_remote_exit(dib);
dibusb_fe_exit(dib);
dibusb_i2c_exit(dib);
- dibusb_pid_list_exit(dib);
dibusb_dvb_exit(dib);
dibusb_urb_exit(dib);
deb_info("init_state should be zero now: %x\n",dib->init_state);
@@ -368,7 +367,6 @@ static int dibusb_init(struct usb_dibusb
if ((ret = dibusb_urb_init(dib)) ||
(ret = dibusb_dvb_init(dib)) ||
- (ret = dibusb_pid_list_init(dib)) ||
(ret = dibusb_i2c_init(dib))) {
dibusb_exit(dib);
return ret;
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
2005-03-22 00:15:37.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
2005-03-22 00:17:09.0 +0100
@@ -22,7 +22,6 @@ static u32 urb_compl_count;
void dibusb_urb_complete(struct urb *urb, struct pt_regs *ptregs)
{
struct usb_dibusb *dib = urb->context;
- int ret;
deb_ts("urb complete feedcount: %d, status: %d, length:
%d\n",dib->feedcount,urb->status,
urb->actual_length);
@@ -45,24 +44,12 @@ void dibusb_urb_complete(struct urb *urb
}
if (dib->feedcount > 0) {
- deb_ts("URB return len: %d\n",urb->actual_length);
- if (urb->actual_length % 188)
- deb_ts("TS Packets: %d, %d\n",
urb->actual_length/188,urb->actual_length % 188);
-
- /* Francois recommends to drop not full-filled packets, even if
they may
-* contain valid TS packets, at least for USB1.1
-*
-* if (urb->actual_length == dib->dibdev->parm->default_size &&
dib->dvb_is_ready) */
if (dib->init_state & DIBUSB_STATE_DVB)
dvb_dmx_swfilter(>demux, (u8*)
urb->transfer_buffer,urb->actual_length);
- else
- deb_ts("URB dropped because of the "
- "actual_length or !dvb_is_ready
(%d).\n",dib->init_state & DIBUSB_STATE_DVB);
} else
deb_ts("URB dropped because of feedcount.\n");
- ret = usb_submit_urb(urb,GFP_ATOMIC);
- deb_ts("urb resubmitted, (%d)\n",ret);
+ usb_submit_urb(urb,GFP_ATOMIC);
}
static int dibusb_ctrl_feed(struct dvb_demux_feed *dvbdmxfeed, int onoff)
@@ -90,11 +77,10 @@ static int dibusb_ctrl_feed(struct dvb_d
dib->feedcount = newfeedcount;
- /* get a free pid from the list and activate it on the device
-* specific pid_filter
-*/
- if (dib->pid_parse)
- dibusb_ctrl_pid(dib,dvbdmxfeed,onoff);
+ /* activate the pid on the device specific
[DVB patch 19/48] support KWorld/ADSTech Instant DVB-T USB2.0
o added support for KWorld/ADSTech Instant DVB-T USB2.0 (DiB3000M-B) o added deactivation option of the pid parser for the DiB3000M-B (since there are USB2.0 devices and which now have the ability to deliver the complete Transport Stream) (Patrick Boettcher) Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> Documentation/dvb/README.dibusb| 14 +++-- drivers/media/dvb/dibusb/Kconfig |3 - drivers/media/dvb/dibusb/dvb-dibusb-core.c | 78 +++-- drivers/media/dvb/dibusb/dvb-dibusb-usb.c |4 + drivers/media/dvb/dibusb/dvb-dibusb.h |1 drivers/media/dvb/frontends/dib3000mb.c|5 + drivers/media/dvb/frontends/dib3000mc.c|2 7 files changed, 83 insertions(+), 24 deletions(-) Index: linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb === --- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/README.dibusb 2005-03-22 00:15:09.0 +0100 +++ linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb2005-03-22 00:16:19.0 +0100 @@ -77,6 +77,8 @@ Supported devices USB2.0 - Hauppauge WinTV NOVA-T USB2 http://www.hauppauge.com/ +- KWorld/ADSTech Instant DVB-T USB2.0 (DiB3000M-B) + - DiBcom USB2.0 DVB-T reference device (non-public) 1) It is working almost. @@ -84,12 +86,13 @@ Supported devices USB2.0 0. NEWS: - 2004-02-02 - added support for the Hauppauge Win-TV Nova-T USB2 - 2004-01-31 - distorted streaming is finally gone for USB1.1 devices - 2004-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb + 2005-02-11 - added support for the KWorld/ADSTech Instant DVB-T USB2.0. Thanks a lot to Joachim von Caron + 2005-02-02 - added support for the Hauppauge Win-TV Nova-T USB2 + 2005-01-31 - distorted streaming is finally gone for USB1.1 devices + 2005-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb - first almost working version for HanfTek UMT-010 - found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek UMT-010 - 2004-01-10 - refactoring completed, now everything is very delightful + 2005-01-10 - refactoring completed, now everything is very delightful - tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a Panasonic Tuner assembled). Tunerprobing implemented. Thanks a lot to Gunnar Wittich. 2004-12-29 - after several days of struggling around bug of no returning URBs fixed. @@ -260,6 +263,9 @@ Patches, comments and suggestions are ve Bernd Wagner for helping with huge bug reports and discussions. + Gunnar Wittich and Joachim von Caron for their trust for giving me +root-shells on their machines to implement support for new devices. + Some guys on the linux-dvb mailing list for encouraging me Peter Schildmann >peter.schildmann-nospam-at-web.de< for his Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/Kconfig === --- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/Kconfig 2005-03-21 23:27:58.0 +0100 +++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/Kconfig 2005-03-22 00:16:19.0 +0100 @@ -13,7 +13,7 @@ config DVB_DIBUSB TwinhanDTV USB-Ter (VP7041) TwinhanDTV Magic Box (VP7041e) - KWorld V-Stream XPERT DTV - DVB-T USB + KWorld/JetWay/ADSTech V-Stream XPERT DTV - DVB-T USB1.1 and USB2.0 Hama DVB-T USB-Box DiBcom reference devices (non-public) Ultima Electronic/Artec T1 USB TVBOX @@ -23,6 +23,7 @@ config DVB_DIBUSB Artec T1 USB1.1 and USB2.0 boxes Yakumo/Typhoon DVB-T USB2.0 Hanftek UMT-010 USB2.0 + Hauppauge WinTV NOVA-T USB2 The VP7041 seems to be identical to "CTS Portable" (Chinese Television System). Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c === --- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-core.c 2005-03-22 00:15:45.0 +0100 +++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c 2005-03-22 00:16:19.0 +0100 @@ -47,6 +47,7 @@ module_param(rc_query_interval, int, 064 MODULE_PARM_DESC(rc_query_interval, "interval in msecs for remote control query (default: 100; min: 40)"); /* Vendor IDs */ +#define USB_VID_ADSTECH0x06e1 #define USB_VID_ANCHOR 0x0547 #define USB_VID_AVERMEDIA 0x14aa #define USB_VID_COMPRO 0x185b @@ -63,6 +64,8 @@ MODULE_PARM_DESC(rc_query_interval, "int #define USB_VID_ULTIMA_ELECTRONIC 0x05d8 /* Product IDs */ +#define USB_PID_ADSTECH_USB2_COLD 0xa333
[DVB patch 32/48] dibusb: pll fix
o fixed pll frequency calculation for channels > 700 MHz. (Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvb-dibusb-fe-i2c.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
2005-03-22 00:16:28.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
2005-03-22 00:18:55.0 +0100
@@ -278,10 +278,10 @@ static int thomson_cable_eu_pll_set(stru
static int panasonic_cofdm_env57h1xd5_pll_set(struct dvb_frontend_parameters
*fep, u8 pllbuf[4])
{
- u32 freq = fep->frequency;
- u32 tfreq = ((freq + 36125000)*6 + 50) / 100;
+ u32 freq_khz = fep->frequency / 1000;
+ u32 tfreq = ((freq_khz + 36125)*6 + 500) / 1000;
u8 TA, T210, R210, ctrl1, cp210, p4321;
- if (freq > 85800) {
+ if (freq_khz > 858000) {
err("frequency cannot be larger than 858 MHz.");
return -EINVAL;
}
@@ -293,17 +293,17 @@ static int panasonic_cofdm_env57h1xd5_pl
ctrl1 = (1 << 7) | (TA << 6) | (T210 << 3) | R210;
// CHARGE PUMP CONFIG vs RF FREQUENCIES *
- if (freq < 47000)
+ if (freq_khz < 47)
cp210 = 2; // VHF Low and High band ch E12 to E4 to E12
- else if (freq < 52600)
+ else if (freq_khz < 526000)
cp210 = 4; // UHF band Ch E21 to E27
else // if (freq < 86200)
cp210 = 5; // UHF band ch E28 to E69
//*BW select ***
- if (freq < 15300)
+ if (freq_khz < 153000)
p4321 = 1; // BW selected for VHF low
- else if (freq < 47000)
+ else if (freq_khz < 47)
p4321 = 2; // BW selected for VHF high E5 to E12
else // if (freq < 86200)
p4321 = 4; // BW selection for UHF E21 to E69
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4: Alps touchpad too slow
On Mon, Mar 21, 2005 at 02:44:12PM -0800, Andrew Morton wrote: > Andy Isaacson <[EMAIL PROTECTED]> wrote: > > My Vaio r505te comes up with an unusably slow touchpad if I allow the > > ALPS driver to drive it. It says > > > > > ALPS Touchpad (Glidepoint) detected > > > Disabling hardware tapping > > > input: AlpsPS/2 ALPS TouchPad on isa0060/serio1 > > > > and then the trackpad operates at about 1/8 the speed I've gotten used > > to. ... 2.6.11-rc4 ... > > Andy, could you please test 2.6.12-rc1 and let us know which problems > remain? With cvsbk rev 423b66b6oJOGN68OhmSrBFxxLOtIEA (rsynced Monday, it claims to be "2.6.12-rc1"), the situation is much improved. The AlpsPS/2 driver recognizes the trackpad, tracking speed is back to normal, and tapping is turned on by default. (Drat, now I need to figure out how to turn that off again.) The kernel output is a bit odd, though: [ 1200.254707] Adding 987988k swap on /dev/hda3. Priority:-1 extents:1 [ 1200.330453] EXT3 FS on hda2, internal journal [ 1203.504154] SCSI subsystem initialized [ 1204.039053] Enabling hardware tapping [ 1204.099034] ieee1394: Initialized config rom entry `ip1394' [ 1204.266077] input: PS/2 Mouse on isa0060/serio1 [ 1204.400583] input: AlpsPS/2 ALPS GlidePoint on isa0060/serio1 [ 1204.779799] sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]> [ 1206.183165] kjournald starting. Commit interval 5 seconds Note how the "Enabling hardware tapping" message is several lines earlier than it seems it should be... I don't think I'm supposed to be tapping on my SCSI hardware. ... ah, I think I'm missing the "ALPS GlidePoint detected" message which I used to get. Without it, the "Enabling hardware tapping" message is a bit opaque. Other than that, I have no complaints about the trackpad. Thanks for the ping. -andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
scheduler(kernel 2.6) + hyperthreaded related questions?
I went through the sched.c for kernel 2.6 and saw that it supports hyperthreading.I would be glad if someone could answer this question(if am not wrong a HT processor has 2 architectural states and one execution unit...i.e., two pipeline streams) 1)when there are 2 processes a parent and child(created by fork()) do they get scheduled @ the same time...ie., when the parent process is put into one pipeline, do the child also gets scheduled the same time? 2) what abt in the case of threads(I read tht as opposed to kernel2.4,where threads are treated as processes) ..kernel 2.6 treats threads as threads. So, when two paired threads get into execution are they always scheduled at the same time? Also, it would be helpful if someone could suggest which part of sched.c shud i look into to find out how threads are scheduled for a normal processor and for a hyperthreaded processor Pls. CC your replies to this email address [EMAIL PROTECTED] Thanks Arun _ The MSN Survey! http://www.cross-tab.com/surveys/run/test.asp?sid=2026=1 Help us help you better! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC]: DEBUG for PCI IO & MEM allocation
Prarit Bhargava <[EMAIL PROTECTED]> wrote: > > >Shouldn't this also be printing the ->name of the new resource? > > > >A lot of the statements which you're adding will look screwy in an 80-col > >xterm. Please wrap 'em. > > > -- new patch with Andrew's comments fixed. OK, but I've forgotten the rationale for this change - please send through a little changelog entry and a Signed-off-by: line and I'll push this in Greg's direction. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
task_struct change Documentation
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.12-rc1, ./drivers/base/platform.c
On Tuesday 22 March 2005 00:32, All Linux wrote: > The latest prepatch, 2.6.12-rc1, introduced the following change. > > --- a/drivers/base/platform.c 2005-03-17 17:35:04 -08:00 > +++ b/drivers/base/platform.c 2005-03-17 17:35:04 -08:00 > @@ -131,7 +131,7 @@ > pdev->dev.bus = _bus_type; > > if (pdev->id != -1) > -snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s%u", > pdev->name, pdev->id); > +snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s.%u", > pdev->name, pdev->id); > else > strlcpy(pdev->dev.bus_id, pdev->name, BUS_ID_SIZE); > > It causes problem, as most platform files, for example, > arch/ppc/platforms/katana.c, still use the old name without ".". I do > not understand why bus_id "mpsc.0" is better than "mpsc0". > Please explain what is the benefit of introducing such a change, > before I can submit a patch for all those platform files to work with > this change. > Please CC me, as I am currently not in the list. > Devices/drivers ending with a digit, such as i8250, produce "wierd" names - i82500, i82501, etc. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] freepgt: free_pgtables use vma list
On Mon, 21 Mar 2005, David S. Miller wrote: > On Tue, 22 Mar 2005 15:14:54 +1100 > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > Question, Dave: flush_tlb_pgtables after Hugh's patch is also > > possibly not being called with enough range to cover all page > > tables that have been freed. Good question from Nick. > > For example, you may have a single page (start,end) address range > > to free, but if this is enclosed by a large enough (floor,ceiling) > > then it may free an entire pgd entry. > > > > I assume the intention of the API would be to provide the full > > pgd width in that case? > > It just wants the range of page tables liberated. I guess > essentially PMD_SIZE is the granularity. I _think_ that answer means that my current code is fine in this respect. But I'm not entirely convinced. Since sparc64 is the only architecture which implements a flush_tlb_pgtables which actually uses start,end, we do need to suit your needs there - informed reassurance welcome! > Anyways, for the record I made it only call flush_tlb_pgtables() > when end > start, Fine. The patch I just sent, moving the tests, is how I'd like it to be fixed finally, but what you've done in the interim should do fine. > but instead of that BUG() I now get the BUG() > on mm->nr_ptes being non-zero at the end of exit_mmap(). And no way would your change be causing this. Oh dear. > Something is up with the floor/ceiling stuff methinks. Seems so. I did have an off-by-one originally, but that version never leaked out. > It's funny since this code aparently works fine on ia64 which > is fully 3-level too. Hmm... Yes, odd. I'll have to have another think later on. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 27/48] corrected links to firmware files
corrected links to firmware files (reported by Stefan Frings)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
README.dibusb| 19 +--
get_dvb_firmware |2 +-
2 files changed, 14 insertions(+), 7 deletions(-)
Index: linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb
===
--- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/README.dibusb 2005-03-22
00:16:19.0 +0100
+++ linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb2005-03-22
00:18:18.0 +0100
@@ -157,13 +157,20 @@ You can either use "get_dvb_firmware dib
can get it directly via
for USB1.1 (AN2135)
-http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-5.0.0.11.fw?rev=1.1=text/plain
+http://www.linuxtv.org/downloads/firmware/dvb-dibusb-5.0.0.11.fw
for USB1.1 (AN2235) (a few Artec T1 devices)
-http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-an2235-1.fw?rev=1.1=text/plain
+http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
+
+for USB2.0 (FX2) Hauppauge, DiBcom
+http://www.linuxtv.org/downloads/firmware/dvb-dibusb-6.0.0.5.fw
+
+for USB2.0 ADSTech/Kworld USB2.0
+http://www.linuxtv.org/downloads/firmware/dvb-dibusb-adstech-usb2-1.fw
+
+for USB2.0 HanfTek
+http://www.linuxtv.org/downloads/firmware/dvb-dibusb-an2235-1.fw
-for USB2.0 (FX2)
-http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-6.0.0.5.fw?rev=1.1=text/plain
1.2. Compiling
@@ -203,7 +210,7 @@ in vdr is working now also.
2. Known problems and bugs
-- none this time
+- Don't remove the USB device while running an DVB application, your system
will die.
2.1. Adding support for devices
@@ -242,7 +249,7 @@ now use the dmx_sw_filter function inste
linux-dvb software filter is able to get the best of the garbled TS.
The bug, where the TS is distorted by a heavy usage of the device is gone
-definitely. All dibusb-devices I was using (Twinhan, Kworld, DiBcom) are
+definitely. All dibusb-devices I was using (Twinhan, Kworld, DiBcom) are
working like charm now with VDR. Sometimes I even was able to record a channel
and watch another one.
Index: linux-2.6.12-rc1-mm1/Documentation/dvb/get_dvb_firmware
===
--- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/get_dvb_firmware
2005-03-22 00:15:20.0 +0100
+++ linux-2.6.12-rc1-mm1/Documentation/dvb/get_dvb_firmware 2005-03-22
00:18:18.0 +0100
@@ -222,7 +222,7 @@ sub vp7041 {
}
sub dibusb {
- my $url =
"http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-5.0.0.11.fw?rev=1.1=text/plain;;
+ my $url =
"http://www.linuxtv.org/downloads/firmware/dvb-dibusb-5.0.0.11.fw;;
my $outfile = "dvb-dibusb-5.0.0.11.fw";
my $hash = "fa490295a527360ca16dcdf3224ca243";
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 37/48] clear up confusion between ids and adapters
clear up confusion between ids and adapters (Kenneth Aafloy)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvbdev.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dvb-core/dvbdev.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dvb-core/dvbdev.c
2005-03-22 00:27:13.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dvb-core/dvbdev.c2005-03-22
00:27:34.0 +0100
@@ -51,9 +51,10 @@ static const char * const dnames[] = {
"net", "osd"
};
-#define DVB_MAX_IDS 6
-#define nums2minor(num,type,id) ((num << 6) | (id << 4) | type)
-#define MAX_DVB_MINORS (DVB_MAX_IDS*64)
+#define DVB_MAX_ADAPTERS 8
+#define DVB_MAX_IDS4
+#define nums2minor(num,type,id)((num << 6) | (id << 4) | type)
+#define MAX_DVB_MINORS (DVB_MAX_ADAPTERS*64)
static struct class_simple *dvb_class;
@@ -267,7 +268,7 @@ static int dvbdev_get_free_adapter_num (
{
int num = 0;
- while (1) {
+ while (num < DVB_MAX_ADAPTERS) {
struct list_head *entry;
list_for_each (entry, _adapter_list) {
struct dvb_adapter *adap;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 44/48] sparse warnings on one-bit bitfields
Remove some sparse warnings on one-bit bitfields.
Signed-off-by: Peter Hagervall <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvb_ca_en50221.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
2005-03-22 00:28:04.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
2005-03-22 00:28:26.0 +0100
@@ -148,13 +148,13 @@ struct dvb_ca_private {
wait_queue_head_t thread_queue;
/* Flag indicating when thread should exit */
- int exit:1;
+ unsigned int exit:1;
/* Flag indicating if the CA device is open */
- int open:1;
+ unsigned int open:1;
/* Flag indicating the thread should wake up now */
- int wakeup:1;
+ unsigned int wakeup:1;
/* Delay the main thread should use */
unsigned long delay;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix compile warning in drivers/pnp/resource.c with !CONFIG_PCI
Mika Kukkonen <[EMAIL PROTECTED]> wrote:
>
>
> With !CONFIG_PCI I get following warning:
>
>CC drivers/pnp/resource.o
> drivers/pnp/resource.c:24: warning: `pnp_skip_pci_scan' defined but not used
>
> Two ways to fix this, first one would be to simply #ifdef the
> variable. But the variable
> in question is not (according to cscope) actually used outside this
> one other place (and reason why it became a warning now is that Adrian
> made it static), and so the code inside CONFIG_PCI is actually relying
> on the fact that the variable is implicitly initialized to 0.
> So the patch just deletes the variable.
Well Adam might actually have meant to set pnp_skip_pci_scan with a __setup
thingy.
Your patch was wildly wordwrapped.
We have a cute macro for that pci_dev walk.
I queued this up:
---
25/drivers/pnp/resource.c~fix-compile-warning-in-drivers-pnp-resourcec-with-config_pci
2005-03-21 21:57:11.0 -0800
+++ 25-akpm/drivers/pnp/resource.c 2005-03-21 21:58:49.0 -0800
@@ -21,7 +21,6 @@
#include
#include "base.h"
-static int pnp_skip_pci_scan; /* skip PCI resource
scanning */
static int pnp_reserve_irq[16] = { [0 ... 15] = -1 }; /* reserve (don't use)
some IRQ */
static int pnp_reserve_dma[8] = { [0 ... 7] = -1 };/* reserve (don't use)
some DMA */
static int pnp_reserve_io[16] = { [0 ... 15] = -1 }; /* reserve (don't use)
some I/O region */
@@ -385,9 +384,9 @@ int pnp_check_irq(struct pnp_dev * dev,
#ifdef CONFIG_PCI
/* check if the resource is being used by a pci device */
- if (!pnp_skip_pci_scan) {
- struct pci_dev * pci = NULL;
- while ((pci = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pci)) !=
NULL) {
+ {
+ struct pci_dev *pci = NULL;
+ for_each_pci_dev(pci) {
if (pci->irq == *irq)
return 0;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 24/48] av7110: fix Oops when av7110_ir_init() failed
o don't call av7110_ir_init() if driver initialization failed already
due to previous errors (resulted in Oops in out-of-memory conditions) (me)
o don't do av7110_ir_exit if init was not done (Kenneth Aafloy)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
av7110.c| 15 +++
av7110_ir.c |8
2 files changed, 11 insertions(+), 12 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/av7110.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/ttpci/av7110.c 2005-03-21
23:27:57.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/av7110.c 2005-03-22
00:17:56.0 +0100
@@ -2453,6 +2453,9 @@ err_no_mem:
av7110->dvb_adapter->priv = av7110;
frontend_init(av7110);
+#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
+ av7110_ir_init();
+#endif
printk(KERN_INFO "dvb-ttpci: found av7110-%d.\n", av7110_num);
av7110->device_initialized = 1;
av7110_num++;
@@ -2640,18 +2643,6 @@ static int __init av7110_init(void)
{
int retval;
retval = saa7146_register_extension(_extension);
-#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
- if (retval)
- goto failed_saa7146_register;
-
- retval = av7110_ir_init();
- if (retval)
- goto failed_av7110_ir_init;
- return 0;
-failed_av7110_ir_init:
- saa7146_unregister_extension(_extension);
-failed_saa7146_register:
-#endif
return retval;
}
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/av7110_ir.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/ttpci/av7110_ir.c
2005-03-21 23:27:57.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/av7110_ir.c2005-03-22
00:17:56.0 +0100
@@ -12,6 +12,7 @@
/* enable ir debugging by or'ing av7110_debug with 16 */
+static int ir_initialized;
static struct input_dev input_dev;
static u32 ir_config;
@@ -160,6 +161,9 @@ static int av7110_ir_write_proc(struct f
int __init av7110_ir_init(void)
{
+ if (ir_initialized)
+ return 0;
+
static struct proc_dir_entry *e;
init_timer(_timer);
@@ -187,16 +191,20 @@ int __init av7110_ir_init(void)
e->size = 4 + 256 * sizeof(u16);
}
+ ir_initialized = 1;
return 0;
}
void __exit av7110_ir_exit(void)
{
+ if (ir_initialized == 0)
+ return;
del_timer_sync(_timer);
remove_proc_entry("av7110_ir", NULL);
av7110_unregister_irc_handler(av7110_emit_key);
input_unregister_device(_dev);
+ ir_initialized = 0;
}
//MODULE_AUTHOR("Holger Waechtler <[EMAIL PROTECTED]>");
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/5] timers: enable irqs in __mod_timer()
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> If the timer is currently running on another CPU, __mod_timer()
> spins with interrupts disabled and timer->lock held. I think it
> is better to spin_unlock_irqrestore(>lock) in __mod_timer's
> retry path.
>
> This patch is unneccessary long. It is because it tries to cleanup
> the code a bit. I do not like the fact that lock+test+unlock pattern
> is duplicated in the code.
>
> If you think that this patch uglifies the code or does not match
> kernel's coding style - just say nack :)
I've seen worse ;)
I think this makes it a bit more kernel-like?
--- 25/kernel/timer.c~timers-enable-irqs-in-__mod_timer-tidy2005-03-21
21:41:03.0 -0800
+++ 25-akpm/kernel/timer.c 2005-03-21 21:41:57.0 -0800
@@ -174,12 +174,13 @@ int __mod_timer(struct timer_list *timer
{
tvec_base_t *old_base, *new_base;
unsigned long flags;
- int new_lock, ret;
+ int new_lock;
+ int ret = -1;
BUG_ON(!timer->function);
check_timer(timer);
- for (ret = -1; ret < 0; ) {
+ do {
spin_lock_irqsave(>lock, flags);
new_base = &__get_cpu_var(tvec_bases);
old_base = timer_base(timer);
@@ -227,7 +228,7 @@ unlock:
if (new_lock)
spin_unlock(_base->lock);
spin_unlock_irqrestore(>lock, flags);
- }
+ } while (ret == -1);
return ret;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Real-Time Preemption and RCU
On Mon, Mar 21, 2005 at 12:23:22AM +0100, Esben Nielsen wrote: > On Sun, 20 Mar 2005, Paul E. McKenney wrote: > > > On Sun, Mar 20, 2005 at 02:29:17PM +0100, Esben Nielsen wrote: > > > On Fri, 18 Mar 2005, Ingo Molnar wrote: > > > > > > > [...] > > > > > > I think it can be deterministic (on the long timescale of memory > > > management) > > > anyway: Boost any non-RT task entering an RCU region to the lowest RT > > > priority. > > > This way only all the RT tasks + one non-RT task can be within those > > > regions. The RT-tasks are supposed to have some kind of upper bound to > > > their CPU-usage. The non-RT task will also finish "soon" as it is > > > boosted. If the RCU batches are also at the lowest RT-priority they can be > > > run immediately after the non-RT task is done. > > > > Hmmm... Sort of a preemptive-first-strike priority boost. Cute! ;-) > > > Well, I was actually thinking of an API like > preempt_by_nonrt_disable() > preempt_by_nonrt_enable() > working like the old preempt_disable()/preempt_enable() but still > allowing RT tasks (as well as priority inheriting non-RT tasks) to be > scheduled. That would kind of help "split" the kernel into two halfs: the > RT part and the non-RT part. The non-RT part would in many ways work as it > has always done. Does sound in some ways similar to the migration approach -- there, the RT/non-RT split is made across CPUs. But if RT is allowed to preempt, then you still have to deal with preemption for locking correctness, right? > > > > clearly the simplest solution is to go with the single-reader locks for > > > > now - a separate experiment could be done with a new type of rwlock that > > > > can only be used by the RCU code. (I'm not quite sure whether we could > > > > guarantee a minimum rate of RCU callback processing under such a scheme > > > > though. It's an eventual memory DoS otherwise.) > > > > > > > > > > Why are a lock needed at all? If it is doable without locking for an > > > non-preemptable SMP kernel it must be doable for an preemptable kernel as > > > well.I am convinced some kind of per-CPU rcu_read_count as I specified in > > > my previous mail can work some way or the other. call_rcu() might need to > > > do more complicated stuff and thus use CPU but call_rcu() is supposed to > > > be an relative rare event not worth optimizing for. Such an > > > implementation will work for any preemptable kernel, not only PREEMPT_RT. > > > For performance is considered it is important not to acquire any locks in > > > the rcu-read regions. > > > > You definitely don't need a lock -- you can just suppress preemption > > on the read side instead. But that potentially makes for long scheduling > > latencies. > > Well, in my patch I do not leave preemption off - only while doing the > simple ++/--. In effect, I let rcu_qsctr_inc know that some RCU reader > might be active, i.e. preempted, on the current CPU such that this isn't > and quiescent point after all. > (To others: Paul nicely unfolded my attachment below - I left it in > the mail such you can read it.) > The problem with this approach is ofcourse that user space programs might > preempt an RCU reader for a very long time such that RCU batches are never > really run. The boosting of non-RT tasks mentioned above would help a > lot. > A plus(?) in it: You can actually sleep while having the rcu_read_lock !! This is in some ways similar to the K42 approach to RCU (which they call "generations"). Dipankar put together a similar patch for Linux, but the problem was that grace periods could be deferred for an extremely long time. Which I suspect is what you were calling out as causing RCU batches never to run. > > The counter approach might work, and is also what the implementation #5 > > does -- check out rcu_read_lock() in Ingo's most recent patch. > > > > Do you refer to your original mail with implementing it in 5 steps? > In #5 in that one (-V0.7.41-00, right?) you use a lock and as you say that > forces syncronization between the CPUs - bad for scaling. It does make the > RCU batches somewhat deterministic, as the RCU task can boost the readers > to the rcu-task's priority. > The problem about this approach is that everybody calling into RCU code > have a worst case behaviour of the systemwide worst case RCU reader > section - which can be pretty large (in principle infinite if somebody.) > So if somebody uses a call to a function in the code containing a RCU read > area the worst case behavious would be the same as teh worst case latency > in the simple world where preempt_disable()/preempt_enable() was used. I missed something here -- readers would see the worst-case -writer- latency rather than the worst-case -reader- latency, right? Or are you concerned about the case where some reader blocks the write-side acquisitions in _synchronize_kernel(), but not before the writer has grabbed a lock, blocking any readers on the corresponding CPU? Yes, but this is
Re: [PATCH 1/5] freepgt: free_pgtables use vma list
On Mon, 21 Mar 2005, David S. Miller wrote: > > flush_tlb_pgtables() on sparc64 has a BUG() check which > is basically: > > BUG((long)start > (long)end); > > This catches two cases of bogus arguments: > > 1) start --> end straddles sparc64 address space hole That's an interesting remark. I hadn't noticed the signed long type. I believe the vma gathering in free_pgtables will have no problem with that, but what about the old code? What happens if an app does a huge munmap straddling the address space hole? Or is all the user address space below the hole? Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] freepgt: free_pgtables use vma list
Many thanks for the testing.
On Mon, 21 Mar 2005, David S. Miller wrote:
>
> This adjustment of addr relative to floor is very
> strange, it can advance "addr" (and thus "start")
> past the end of the VMA we are unmapping.
Not strange, it's just trying to skip a pointless iteration.
> In fact, it is miraculious that this free_pud_range()
> calling loop terminates properly! Actually, it is
> no mystery, since the next PGD address is the same
> for both the original and adjusted value of "addr".
> So the loop terminates after the first iteration.
Miraculous indeed, I hadn't realized those do {} while () loops
were as robust as that. But it's certainly wrong to have been
calling them once in this case, even if they did recover.
> Anyways, there's the full analysis, what do you make
> of this Hugh? :-)
Much better than I deserve. Silly me. This patch should fix it.
[PATCH 6/5] freepgt: fix addr,end check
Fix placing of free_p?d_range's check for addr against end.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
--- freepgt5/mm/memory.c2005-03-22 04:28:40.0 +
+++ freepgt6/mm/memory.c2005-03-22 05:11:05.0 +
@@ -127,11 +127,6 @@ static inline void free_pmd_range(struct
unsigned long next;
unsigned long start;
- if (end - 1 > ceiling - 1)
- end -= PMD_SIZE;
- if (addr > end - 1)
- return;
-
start = addr;
pmd = pmd_offset(pud, addr);
do {
@@ -202,7 +197,9 @@ void free_pgd_range(struct mmu_gather **
return;
}
ceiling &= PMD_MASK;
- if (addr > ceiling - 1)
+ if (end - 1 > ceiling - 1)
+ end -= PMD_SIZE;
+ if (addr > end - 1)
return;
start = addr;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-01
On Mon, Mar 21, 2005 at 10:06:22AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > got this early-bootup crash on an SMP box:
> >
> > the same kernel image boots fine on an UP box, so it's an SMP bug.
> >
> > note that the same occurs with your latest (synchronization barrier)
> > fixes applied as well.
>
> i've uploaded my current tree (-V0.7.41-01) to:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> it includes the latest round of RCU fixes - but doesnt solve the SMP
> bootup crash.
Hello, Ingo,
Does the following help with the SMP problem? This fix and the earlier
one make my old patch survive a few rounds of kernbench on a 4-CPU x86
box. (Yes, I am still being cowardly! But happy that the test system
is alive again!) Without these fixes, it too dies during boot.
Thanx, Paul
diff -urpN -X dontdiff linux-2.6.11.fixes2/kernel/rcupdate.c
linux-2.6.11.fixes3/kernel/rcupdate.c
--- linux-2.6.11.fixes2/kernel/rcupdate.c Mon Mar 21 08:17:00 2005
+++ linux-2.6.11.fixes3/kernel/rcupdate.c Mon Mar 21 20:00:00 2005
@@ -633,7 +633,7 @@ void rcu_check_callbacks(int cpu, int us
{
if ((unsigned long)(jiffies - rcu_ctrlblk.last_sk) >
HZ/GRACE_PERIODS_PER_SEC) {
- synchronize_kernel();
+ _synchronize_kernel();
rcu_advance_callbacks();
rcu_process_callbacks();
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
It is not so much selling, in my view, as putting in context. If one can simply explain to others what is before them, so that they can quickly understand its purposes, scope, architecture, limitations, alternatives, and such, then others can quickly evaluate what it is, and whether such seems like a good idea. It doesn't necessarily mean they buy it any quicker. Sometimes it just means it gets shot down quicker ;). That's ok. There's a _lot_ of stuff that flows by here ... be gentle and helpfully informative to the poor reader ... as best you can. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Hi Pavel, On Mon, Mar 21, 2005 at 08:00:44PM +0100, Pavel Machek wrote: > Perhaps squashfs is good enough improvement over cramfs... But I'd > like those 4Gb limits to go away. Well, squashfs is an *excellent* filesystem with very high compression ratios and high speed on slow I/O devices such as CDs. I now use it to store my root FS in initrd, and frankly, having a fully functionnal OS in an image as small as 7 MB is "a good enough improvement over cramfs". If the 4 GB limit goes away one day, I hope it will not increase overall image size significantly, because *this* would then become a regression. Perhaps it would simply need to be a different version and different format (eg: squashfs v3) just as we had ext, then ext2, or jffs then jffs2, etc... Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-01
On Tue, Mar 22, 2005 at 12:10:14AM +0100, Magnus Naeslund(t) wrote:
> Ingo Molnar wrote:
> >
> >i've uploaded my current tree (-V0.7.41-01) to:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> >it includes the latest round of RCU fixes - but doesnt solve the SMP
> >bootup crash.
> >
> > Ingo
>
> With this kernel I can run for some 20 minutes, then the ip_dst_cache
> overflows.
> I gather it has something to do with RCU...
>
> If I just let it run and grep ip_dst_cache /proc/slab it goes up to 4096
> (max) and then the printk's are starting, and the networks stops.
> After i up the limit to the double (echo "8192" >
> /proc/sys/net/ipv4/route/max_size) network starts to work again.
> But of course, after a while it overflows again:
>
> # grep ip_dst_cache /proc/slabinfo
> ip_dst_cache8192 8205256 151 : tunables 168
> 0 : slabdata547547 0
>
> I haven't tried the vanilla 2.6.12-rc2 kernel, and I don't have the time
> to do that right now, but i figured it would have something to do with
> your patch. Older 2.6.8 works just fine.
Hello, Magnus,
I believe that my earlier patch might take care of this (included again
for convenience).
Thanx, Paul
Signed-off-by: <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.11.fixes/kernel/rcupdate.c
linux-2.6.11.fixes2/kernel/rcupdate.c
--- linux-2.6.11.fixes/kernel/rcupdate.cMon Mar 21 08:14:47 2005
+++ linux-2.6.11.fixes2/kernel/rcupdate.c Mon Mar 21 08:17:00 2005
@@ -620,7 +620,7 @@ static void rcu_process_callbacks(void)
return;
}
rdp->donelist = NULL;
- rdp->donetail = >waitlist;
+ rdp->donetail = >donelist;
put_cpu_var(rcu_data);
while (list) {
next = list->next;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. > I have agreed to drop V1.0 support, and yes (as explained in another > emauil), breaking the 4GB limit does involve on-disk format change. I've only also been reading this thread with half an eye but : Would it be possible (in some logical timeframe) to change the filesystem's on-disk format to support larger sizes without actually changing the rest of the code? I don't know where the 4GB limit comes from in this case but if you would change the on-disk format, the format itself, then I would think it would make it easier to swallow the filesystem and then when it's in the kernel you can actually make it support more than 4GB. Then there at least wouldn't need to be a switch in the format when it's in the kernel. Just my thought - just feels like it might make it included faster. And hell, if it's not possible, just ignore what I wrote. // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCP68hBrn2kJu9P78RAoGVAJ9a2cjFAv6NW8qyd336wEK5VcJf7gCfV5Oc gswa6cSH7o3ND+lse64LLxI= =D8rp -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.12-rc1, ./drivers/base/platform.c
The latest prepatch, 2.6.12-rc1, introduced the following change. --- a/drivers/base/platform.c 2005-03-17 17:35:04 -08:00 +++ b/drivers/base/platform.c 2005-03-17 17:35:04 -08:00 @@ -131,7 +131,7 @@ pdev->dev.bus = _bus_type; if (pdev->id != -1) -snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s%u", pdev->name, pdev->id); +snprintf(pdev->dev.bus_id, BUS_ID_SIZE, "%s.%u", pdev->name, pdev->id); else strlcpy(pdev->dev.bus_id, pdev->name, BUS_ID_SIZE); It causes problem, as most platform files, for example, arch/ppc/platforms/katana.c, still use the old name without ".". I do not understand why bus_id "mpsc.0" is better than "mpsc0". Please explain what is the benefit of introducing such a change, before I can submit a patch for all those platform files to work with this change. Please CC me, as I am currently not in the list. Thanks, Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SATA] sata-via : bug?
Any modes in the bios for the SATA ports? Maybe it is in a mode not supported by linux. I know the ICH5 only wanted to work for me in native (enhanced?) mode, not compatible (emulating PATA) mode. Maybe via does something similar. I am puzzles by the UDMA/133 message which makes no sense for SATA which should be 150 or 300 not 133. Len Sorensen Len, Thanks for the suggestion but I do not have any option of turning any modes on in the BIOS. At this point I am thinking/hoping that this is quirk introduced by mobo that is triggering this behavior in the driver that can be fixed by somebody easily. Although I do not have the skill set to device a solution. Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] freepgt: free_pgtables use vma list
On Tue, 22 Mar 2005 15:14:54 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > Question, Dave: flush_tlb_pgtables after Hugh's patch is also > possibly not being called with enough range to cover all page > tables that have been freed. > > For example, you may have a single page (start,end) address range > to free, but if this is enclosed by a large enough (floor,ceiling) > then it may free an entire pgd entry. > > I assume the intention of the API would be to provide the full > pgd width in that case? It just wants the range of page tables liberated. I guess essentially PMD_SIZE is the granularity. Anyways, for the record I made it only call flush_tlb_pgtables() when end > start, but instead of that BUG() I now get the BUG() on mm->nr_ptes being non-zero at the end of exit_mmap(). Something is up with the floor/ceiling stuff methinks. It's funny since this code aparently works fine on ia64 which is fully 3-level too. Hmm... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel bug: futex_wait hang
On Mon, 2005-03-21 at 21:08 -0800, Andrew Morton wrote: > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > > > The most recent messages under "Futex queue_me/get_user ordering", > > with a patch from Jakub Jelinek will fix this problem by changing the > > kernel. Yes, you should apply Jakub's most recent patch, message-ID > > "<[EMAIL PROTECTED]>". > > > > I have not tested the patch, but it looks convincing. > > OK, thanks. Lee && Paul, that's at > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/broken-out/futex-queue_me-get_user-ordering-fix.patch > Does not fix the problem. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 10/48] dibusb: support Hauppauge WinTV NOVA-T USB2
o added support for Hauppauge WinTV NOVA-T USB2 (clone of MOD3000P by DiBcom)
(Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
Documentation/dvb/README.dibusb|8 ++--
drivers/media/dvb/dibusb/dvb-dibusb-core.c | 28 +++-
2 files changed, 25 insertions(+), 11 deletions(-)
Index: linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb
===
--- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/README.dibusb 2005-03-22
00:15:04.0 +0100
+++ linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb2005-03-22
00:15:09.0 +0100
@@ -1,4 +1,4 @@
-Documentation for dib3000mb frontend driver and dibusb device driver
+Documentation for dib3000* frontend drivers and dibusb device driver
Copyright (C) 2004-5 Patrick Boettcher ([EMAIL PROTECTED]),
@@ -74,6 +74,9 @@ Supported devices USB2.0
- Artec T1 USB TVBOX (FX2) (2)
+- Hauppauge WinTV NOVA-T USB2
+ http://www.hauppauge.com/
+
- DiBcom USB2.0 DVB-T reference device (non-public)
1) It is working almost.
@@ -81,10 +84,11 @@ Supported devices USB2.0
0. NEWS:
+ 2004-02-02 - added support for the Hauppauge Win-TV Nova-T USB2
2004-01-31 - distorted streaming is finally gone for USB1.1 devices
2004-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb
- first almost working version for HanfTek UMT-010
- - found out, that Yakumo/HAMA/Typhoon are predessors of the
HanfTek
+ - found out, that Yakumo/HAMA/Typhoon are predessors of the
HanfTek UMT-010
2004-01-10 - refactoring completed, now everything is very delightful
- tuner quirks for some weird devices (Artec T1 AN2235 device has
sometimes a
Panasonic Tuner assembled). Tunerprobing implemented. Thanks a
lot to Gunnar Wittich.
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-21 23:27:58.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:15:09.0 +0100
@@ -55,8 +55,9 @@ MODULE_PARM_DESC(rc_query_interval, "int
#define USB_VID_DIBCOM 0x10b8
#define USB_VID_EMPIA 0xeb1a
#define USB_VID_GRANDTEC 0x5032
-#define USB_VID_HYPER_PALTEK 0x1025
#define USB_VID_HANFTEK0x15f4
+#define USB_VID_HAUPPAUGE 0x2040
+#define USB_VID_HYPER_PALTEK 0x1025
#define USB_VID_IMC_NETWORKS 0x13d3
#define USB_VID_TWINHAN0x1822
#define USB_VID_ULTIMA_ELECTRONIC 0x05d8
@@ -93,6 +94,8 @@ MODULE_PARM_DESC(rc_query_interval, "int
#define USB_PID_HANFTEK_UMT_010_WARM 0x0025
#define USB_PID_YAKUMO_DTT200U_COLD0x0201
#define USB_PID_YAKUMO_DTT200U_WARM0x0301
+#define USB_PID_WINTV_NOVA_T_USB2_COLD 0x9300
+#define USB_PID_WINTV_NOVA_T_USB2_WARM 0x9301
/* USB Driver stuff
* table of devices that this driver is working with
@@ -143,16 +146,18 @@ static struct usb_device_id dib_table []
/* 28 */ { USB_DEVICE(USB_VID_HANFTEK,
USB_PID_HANFTEK_UMT_010_COLD) },
/* 29 */ { USB_DEVICE(USB_VID_HANFTEK,
USB_PID_HANFTEK_UMT_010_WARM) },
+/* 30 */ { USB_DEVICE(USB_VID_HAUPPAUGE,
USB_PID_WINTV_NOVA_T_USB2_COLD) },
+/* 31 */ { USB_DEVICE(USB_VID_HAUPPAUGE,
USB_PID_WINTV_NOVA_T_USB2_WARM) },
/*
* activate the following define when you have one of the devices and want to
* build it from build-2.6 in dvb-kernel
*/
// #define CONFIG_DVB_DIBUSB_MISDESIGNED_DEVICES
#ifdef CONFIG_DVB_DIBUSB_MISDESIGNED_DEVICES
-/* 30 */ { USB_DEVICE(USB_VID_ANCHOR,
USB_PID_ULTIMA_TVBOX_ANCHOR_COLD) },
-/* 31 */ { USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
-/* 32 */ { USB_DEVICE(USB_VID_ANCHOR,
USB_PID_ULTIMA_TVBOX_USB2_FX_WARM) },
-/* 33 */ { USB_DEVICE(USB_VID_ANCHOR,
USB_PID_DIBCOM_ANCHOR_2135_COLD) },
+/* 32 */ { USB_DEVICE(USB_VID_ANCHOR,
USB_PID_ULTIMA_TVBOX_ANCHOR_COLD) },
+/* 33 */ { USB_DEVICE(USB_VID_CYPRESS,
USB_PID_ULTIMA_TVBOX_USB2_FX_COLD) },
+/* 34 */ { USB_DEVICE(USB_VID_ANCHOR,
USB_PID_ULTIMA_TVBOX_USB2_FX_WARM) },
+/* 35 */ { USB_DEVICE(USB_VID_ANCHOR,
USB_PID_DIBCOM_ANCHOR_2135_COLD) },
#endif
{ } /* Terminating entry */
[DVB patch 23/48] ttusb-budget: s/usb_unlink_urb/usb_kill_urb/
patch by Colin Western: s/usb_unlink_urb/usb_kill_urb/ Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> dvb-ttusb-budget.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c === --- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c 2005-03-22 00:17:09.0 +0100 +++ linux-2.6.12-rc1-mm1/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c 2005-03-22 00:17:50.0 +0100 @@ -818,7 +818,7 @@ static void ttusb_stop_iso_xfer(struct t int i; for (i = 0; i < ISO_BUF_COUNT; i++) - usb_unlink_urb(ttusb->iso_urb[i]); + usb_kill_urb(ttusb->iso_urb[i]); ttusb->iso_streaming = 0; } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 33/48] tda10021: fix continuity errors
Fix Continuity Errors with tda10021 (slickhenry, Robert Schlabbach)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
tda10021.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/tda10021.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/tda10021.c
2005-03-22 00:16:28.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/tda10021.c 2005-03-22
00:23:32.0 +0100
@@ -66,7 +66,7 @@ static u8 tda10021_inittab[0x40]=
{
0x73, 0x6a, 0x23, 0x0a, 0x02, 0x37, 0x77, 0x1a,
0x37, 0x6a, 0x17, 0x8a, 0x1e, 0x86, 0x43, 0x40,
- 0xb8, 0x3f, 0xa1, 0x00, 0xcd, 0x01, 0x00, 0xff,
+ 0xb8, 0x3f, 0xa0, 0x00, 0xcd, 0x01, 0x00, 0xff,
0x11, 0x00, 0x7c, 0x31, 0x30, 0x20, 0x00, 0x00,
0x02, 0x00, 0x00, 0x7d, 0x00, 0x00, 0x00, 0x00,
0x07, 0x00, 0x33, 0x11, 0x0d, 0x95, 0x08, 0x58,
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: And people merging xfs/reiserfs4/etc did address problems pointed out in their code. Where did I say I wasn't addressing the problems pointed out in the code. All the issues I can fix I am addressing. Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm2 + Radeon crash
On Mon, 21 Mar 2005 15:43:32 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > Christian Henz <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I wanted to try 2.6.11-mm2 for the low latency/realtime lsm stuff and > > I've run into a severe > > problem. > > Christian, some fixes have bene made in this area. Could you please test > 2.6.12-rc1-mm1? > I've only tried once so far and again it immediately rebooted after running startx. I will try later today to catch that condition where only X crashes but the XFree68.log gets written. cheers, Christian dmesg-2.6.12-rc1-mm1-1.gz Description: application/gzip
Re: kernel bug: futex_wait hang
Jamie Lokier <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > iirc we ended up deciding that the futex problems around that time were due > > to userspace problems (a version of libc). But then, there's no discussion > > around Seto's patch and it didn't get applied. So I don't know what > > happened to that work - it's all a bit mysterious. > > It can be fixed _either_ in Glibc, or by changing the kernel. > > That problem is caused by differing assumptions between Glibc and the > kernel about subtle futex semantics. Which goes to show they are > really clever, or something. > > I provided pseudo-code for the Glibc fix, but not an actual patch > because NPTL is quite complicated and I wanted to know the Glibc > people were interested, but apparently they were too busy at the time > - benchmarks would have made sense for such a patch. > > Scott Snyder started fixing part of Glibc, and that did fix his > instance of this problem so we know the approach works. But a full > patch for Glibc was not prepared. > > The most recent messages under "Futex queue_me/get_user ordering", > with a patch from Jakub Jelinek will fix this problem by changing the > kernel. Yes, you should apply Jakub's most recent patch, message-ID > "<[EMAIL PROTECTED]>". > > I have not tested the patch, but it looks convincing. OK, thanks. Lee && Paul, that's at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/broken-out/futex-queue_me-get_user-ordering-fix.patch > I argued for fixing Glibc on the grounds that the changed kernel > behaviour, or more exactly having Glibc depend on it, loses a certain > semantic property useful for unusual operations on multiple futexes at > the same time. But I appear to have lost the argument, and Jakub's > latest patch does clean up some cruft quite nicely, with no expected > performance hit. Futexes were initially so simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi! Perhaps squashfs is good enough improvement over cramfs... But I'd like those 4Gb limits to go away. So would I. But it is a totally groundless reason to refuse kernel submission because of that, Squashfs users are quite happily using it with such a "terrible" limitation. I'm asking for Squashfs to be put in the kernel _now_ because users are asking me to do it _now_. If it Putting it into kernel because users want it is... not a good reason. You should put it there if it is right thing to do. I believe you should address those endianness issues and drop V1 support. If breaking 4GB limit does not involve on-disk format change, it may be okay to merge. After code is merged, doing format changes will be hard... Pavel So users don't matter anymore, now that's a terrible admission to make. Linux wouldn't be where it is today without all those "mere" users. I obviously think putting Squashfs into the kernel is the right thing to do. The filesystem is endian safe and has been since the first release - it works on big endian and little endian, and every architecure I've tried it on it works (Intel 32/64, PowerPC 32/64. MIPS, ARM, Sparx). The endian code which everyone seems to have got so worked up about is there to _make_ it endian safe. I've already explained why making Squashfs natively support both little endian and big endian is important for embedded systems. I have agreed to drop V1.0 support, and yes (as explained in another emauil), breaking the 4GB limit does involve on-disk format change. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel bug: futex_wait hang
On Tue, 2005-03-22 at 04:48 +, Jamie Lokier wrote: > I argued for fixing Glibc on the grounds that the changed kernel > behaviour, or more exactly having Glibc depend on it, loses a certain > semantic property useful for unusual operations on multiple futexes at > the same time. But I appear to have lost the argument, and Jakub's > latest patch does clean up some cruft quite nicely, with no expected > performance hit. A glibc fix will take forever to get to users compared to a kernel fix. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389
Will this do it for the moment?
If so, lets use it until Pavel's flag-day is over -- when we'll send an
updated patch.
thanks,
-Len
= drivers/pci/pci-acpi.c 1.4 vs edited =
--- 1.4/drivers/pci/pci-acpi.c 2005-03-03 04:28:23 -05:00
+++ edited/drivers/pci/pci-acpi.c 2005-03-21 22:59:39 -05:00
@@ -237,19 +237,8 @@
static int acpi_pci_choose_state(struct pci_dev *pdev, pm_message_t state)
{
- char dstate_str[] = "_S0D";
- acpi_status status;
- unsigned long val;
- struct device *dev = >dev;
+ /* TBD */
- /* Fixme: the check is wrong after pm_message_t is a struct */
- if ((state >= PM_SUSPEND_MAX) || !DEVICE_ACPI_HANDLE(dev))
- return -EINVAL;
- dstate_str[2] += state; /* _S1D, _S2D, _S3D, _S4D */
- status = acpi_evaluate_integer(DEVICE_ACPI_HANDLE(dev), dstate_str,
- NULL, );
- if (ACPI_SUCCESS(status))
- return val;
return -ENODEV;
}
[DVB patch 15/48] dibusb: increased the number of urbs for usb1.1 devices
increased the number of urbs for usb1.1 devices (Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvb-dibusb-core.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:15:09.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c
2005-03-22 00:15:45.0 +0100
@@ -204,7 +204,7 @@ static struct dibusb_device_class dibusb
{ .id = DIBUSB1_1, .usb_ctrl = _usb_ctrl[0],
.firmware = "dvb-dibusb-5.0.0.11.fw",
.pipe_cmd = 0x01, .pipe_data = 0x02,
- .urb_count = 3, .urb_buffer_size = 4096,
+ .urb_count = 5, .urb_buffer_size = 4096,
DIBUSB_RC_NEC_PROTOCOL,
_demod[DIBUSB_DIB3000MB],
_tuner[DIBUSB_TUNER_CABLE_THOMSON],
@@ -212,7 +212,7 @@ static struct dibusb_device_class dibusb
{ DIBUSB1_1_AN2235, _usb_ctrl[1],
"dvb-dibusb-an2235-1.fw",
0x01, 0x02,
- 3, 4096,
+ 5, 4096,
DIBUSB_RC_NEC_PROTOCOL,
_demod[DIBUSB_DIB3000MB],
_tuner[DIBUSB_TUNER_CABLE_THOMSON],
@@ -231,7 +231,6 @@ static struct dibusb_device_class dibusb
15, 188*21,
DIBUSB_RC_NO,
_demod[DIBUSB_MT352],
-// _tuner[DIBUSB_TUNER_COFDM_PANASONIC_ENV77H11D5],
_tuner[DIBUSB_TUNER_CABLE_LG_TDTP_E102P],
},
};
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 17/48] l64781: email address fix
fix marko kohtala's mail address Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> l64781.c |5 ++--- l64781.h |5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-) Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/l64781.c === --- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/l64781.c 2005-03-21 23:27:58.0 +0100 +++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/l64781.c 2005-03-22 00:15:55.0 +0100 @@ -1,9 +1,8 @@ /* driver for LSI L64781 COFDM demodulator -Copyright (C) 2001 Holger Waechtler <[EMAIL PROTECTED]> - for Convergence Integrated Media GmbH - Marko Kohtala <[EMAIL PROTECTED]> +Copyright (C) 2001 Holger Waechtler for Convergence Integrated Media GmbH + Marko Kohtala <[EMAIL PROTECTED]> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/l64781.h === --- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/l64781.h 2005-03-21 23:27:58.0 +0100 +++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/l64781.h 2005-03-22 00:15:55.0 +0100 @@ -1,9 +1,8 @@ /* driver for LSI L64781 COFDM demodulator -Copyright (C) 2001 Holger Waechtler <[EMAIL PROTECTED]> - for Convergence Integrated Media GmbH - Marko Kohtala <[EMAIL PROTECTED]> +Copyright (C) 2001 Holger Waechtler for Convergence Integrated Media GmbH + Marko Kohtala <[EMAIL PROTECTED]> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 09/48] dibusb readme update
dibusb readme update (Patrick Boettcher) Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> README.dibusb | 57 + 1 files changed, 25 insertions(+), 32 deletions(-) Index: linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb === --- linux-2.6.12-rc1-mm1.orig/Documentation/dvb/README.dibusb 2005-03-21 23:27:58.0 +0100 +++ linux-2.6.12-rc1-mm1/Documentation/dvb/README.dibusb2005-03-22 00:15:04.0 +0100 @@ -1,7 +1,7 @@ Documentation for dib3000mb frontend driver and dibusb device driver -Copyright (C) 2004 Patrick Boettcher ([EMAIL PROTECTED]), +Copyright (C) 2004-5 Patrick Boettcher ([EMAIL PROTECTED]), dibusb and dib3000mb/mc drivers based on GPL code, which has @@ -46,7 +46,7 @@ Produced and reselled by KWorld: Others: --- -- Ultima Electronic/Artec T1 USB TVBOX (AN2135, AN2235, AN2235 with Panasonic Tuner) +- Ultima Electronic/Artec T1 USB TVBOX (AN2135, AN2235, AN2235 with Panasonic Tuner) http://82.161.246.249/products-tvbox.html - Compro Videomate DVB-U2000 - DVB-T USB (2) @@ -77,16 +77,17 @@ Supported devices USB2.0 - DiBcom USB2.0 DVB-T reference device (non-public) 1) It is working almost. -2) No test reports received yet. +2) No test reports received yet. 0. NEWS: + 2004-01-31 - distorted streaming is finally gone for USB1.1 devices 2004-01-13 - moved the mirrored pid_filter_table back to dvb-dibusb - first almost working version for HanfTek UMT-010 - found out, that Yakumo/HAMA/Typhoon are predessors of the HanfTek 2004-01-10 - refactoring completed, now everything is very delightful - tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a - Panasonic Tuner assembled). Tunerprobing implemented. Thanks a lot to Gunnar Wittich. + Panasonic Tuner assembled). Tunerprobing implemented. Thanks a lot to Gunnar Wittich. 2004-12-29 - after several days of struggling around bug of no returning URBs fixed. 2004-12-26 - refactored the dibusb-driver, splitted into separate files - i2c-probing enabled @@ -106,7 +107,7 @@ Supported devices USB2.0 2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek) 2004-09-20 - added support for a new device (Compro DVB-U2000), thanks to Amaury Demol for reporting - - changed usb TS transfer method (several urbs, stopping transfer + - changed usb TS transfer method (several urbs, stopping transfer before setting a new pid) 2004-09-13 - added support for a new device (Artec T1 USB TVBOX), thanks to Christian Motschke for reporting @@ -191,13 +192,13 @@ turned on. At this point you should be able to start a dvb-capable application. For myself I used mplayer, dvbscan, tzap and kaxtv, they are working. Using the device -in vdr (at least the USB2.0 one) is working. +in vdr is working now also. 2. Known problems and bugs - none this time -2.1. Adding support for devices +2.1. Adding support for devices It is not possible to determine the range of devices based on the DiBcom reference designs. This is because the reference design of DiBcom can be sold @@ -213,53 +214,45 @@ of the device. I will add it to this lis others. If you are familar with C you can also add the VID and PID of the device to -the dvb-dibusb.h-file and create a patch and send it over to me or to +the dvb-dibusb-core.c-file and create a patch and send it over to me or to the linux-dvb mailing list, _after_ you have tried compiling and modprobing it. 2.2. USB1.1 Bandwidth limitation -Most of the current supported devices are USB1.1 and thus they have a +Most of the currently supported devices are USB1.1 and thus they have a maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub. This is not enough for receiving the complete transport stream of a DVB-T channel (which can be about 16 MBit/s). Normally this is not a problem, if you only want to watch TV (this does not apply for HDTV), -but watching a channel while recording another channel on the same -frequency simply does not work. This applies to all USB1.1 DVB-T -devices, not only dibusb) - -A special problem of the dibusb for the USB1.1 is, that the USB control -IC has a problem with write accesses while having MPEG2-streaming -enabled. When you set another pid while receiving MPEG2-TS it happens, that -the stream is disturbed and probably data is lost (results in distortions of -the video or strange beeps within the audio stream). DiBcom is preparing a -firmware especially for Linux which perhaps solves the problem. - -Especially VDR users are victoms of this bug. VDR frequently requests new PIDs -due the automatic scanning
Re: [PATCH 1/5] freepgt: free_pgtables use vma list
On Mon, 2005-03-21 at 15:02 -0800, David S. Miller wrote: > Anyways, there's the full analysis, what do you make > of this Hugh? :-) Impressive, and my name isn't even Hugh. Question, Dave: flush_tlb_pgtables after Hugh's patch is also possibly not being called with enough range to cover all page tables that have been freed. For example, you may have a single page (start,end) address range to free, but if this is enclosed by a large enough (floor,ceiling) then it may free an entire pgd entry. I assume the intention of the API would be to provide the full pgd width in that case? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.1[01] freeze on x86_64
Hello, One liner: I'm getting mysterious (to me), almost random hard freezes of the kernel running 2.6.10 and 2.6.11. Kernel version: Linux version 2.6.11-gentoo-r3 ([EMAIL PROTECTED]) (gcc version 3.4.2 (Gentoo Linux 3.4.2-r2, ssp-3.4.1-1, pie-8.7.6.5)) Mark Nipper posted a message on March 5 regarding some mysterious kernel lockups which he didn't get a response to (I've contacted him about it). Since I'm having what I think is the same problem, I thought I'd post a message so he's not just a single lonely voice in the dark. Mark and I have similar set-ups. We're both running x86_64 kernels, and ReiserFS3. He's running Debian, I'm running Gentoo. We haven't compared kernel config files yet; it might mean something to him, but to be honest, I barely know enough to compile my own kernels and wouldn't know where to begin to look for the problem. Mark has only encountered this on 2.6.11, but I don't think he's tried any other kernel versions on x86_64; I get this problem on both 2.6.10 and 2.6.11. I didn't see the problem on 2.6.9. In both of our cases, the kernel is locking up, and requires a power cycle to get it back. We're not able to SSH into our machines, and we get no response from any of the input devices. Furthermore, even with full debugging turned on, there are no messages in the log file that appear to be related to the lockup. In my logs, the last message before the crash is always (that I've noticed) an ACPI error: acpi_thermal-0400 [23] acpi_thermal_get_trip_: Invalid active threshold [0] but this message appears a lot in my logs, so I think it is coincidence. For Mark, the last message was some ReiserFS message. Mark feels like the error is ReiserFS related, and I was pretty sure it was swap related, until I turned off all swap partitions and the problem still occurred. I *may* try converting all of my filesystems to something else if somebody knowledgeable thinks it could be the problem, but I'm guessing it is something deeper in; I've never seen a filesystem related problem that caused a lock-up like this. I still feel that this may be memory related. When I turn off swap, or when a drastically reduce my memory use, my laptop can run for hours, or even days with little use. On the other hand, it can freeze up after five minutes, even before KDE has finished loading completely, with the swap on. However, I haven't found a situation where it won't, eventually, lock up. But I can't really pin it down, so I don't know where the problem is. I haven't noticed the lockups without X, but I haven't run for any great length of time without X. I'm running the ATI proprietary drivers, but I even when I revert to the XOrg ATI drivers (non-proprietary), I still get the lockups. I'm really sorry that I can't provide more information; I'm usually not totally incompetent at narrowing down problems in software, but I have no idea where to even start looking for the problem here. If there are any things I should try that might provide more information, please let me know. I'm attaching my kernel config, plus all of the info from /proc that is suggested by the FAQ to be included. I'll be happy to recompile my kernel with other options, if I can get some hints at starting points; I doubt my changing flags at random will help much. Thanks, in advance. Sean Russell processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 3400+ stepping: 10 cpu MHz : 801.849 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext lm 3dnowext 3dnow bogomips: 1572.86 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000cefff : Video ROM 000cf000-000c : Adapter ROM 000f-000f : System ROM 0010-3fee : System RAM 0010-003ae374 : Kernel code 003ae375-004e0d27 : Kernel data 3fef-3fef9fff : ACPI Tables 3fefa000-3fef : ACPI Non-volatile Storage 3ff0-3fff : reserved 4000-4fff : :00:05.0 4000-4fff : ipw2200 40001000-40001fff : :00:0c.0 d000-d0003fff : :00:06.0 d0004000-d0004fff : :00:0e.0 d0005000-d0005fff : :00:0e.0 d0006000-d0006fff : :00:0e.1 d0007000-d0007fff : :00:0e.1 d0008000-d00087ff : :00:06.0 d0008000-d00087ff : ohci1394 d0008800-d00088ff : :00:08.0 d0008800-d00088ff : r8169 d0008c00-d0008cff : :00:10.3 d0008c00-d0008cff : ehci_hcd d010-d01f : PCI Bus #01 d010-d010 : :01:00.0 d010-d010 : radeonfb
Re: kernel bug: futex_wait hang
On Mon, 2005-03-21 at 20:20 -0800, Andrew Morton wrote: > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > Paul Davis and Chris Morgan have been chasing down a problem with > > xmms_jack and it really looks like this bug, thought to have been fixed > > in 2.6.10, is the culprit. > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.0/2044.html > > > > (for more info google "futex_wait 2.6 hang") > > > > It's simple to reproduce. Run JACK and launch xmms with the JACK output > > plugin. Close XMMS. The xmms process hangs. Strace looks like this: > > > > [EMAIL PROTECTED]:~$ strace -p 7935 > > Process 7935 attached - interrupt to quit > > futex(0xb5341bf8, FUTEX_WAIT, 7939, NULL > > > > Just like in the above bug report, if xmms is run with > > LD_ASSUME_KERNEL=2.4.19, it works perfectly. > > > > I have reproduced the bug with 2.6.12-rc1. > > > > iirc we ended up deciding that the futex problems around that time were due > to userspace problems (a version of libc). But then, there's no discussion > around Seto's patch and it didn't get applied. So I don't know what > happened to that work - it's all a bit mysterious. > It does seem like it could be a different problem. Maybe Paul can provide some more evidence that it's a kernel and not a glibc/NPTL bug. I'm really just posting this on Paul's behalf; I don't claim to understand the issue. ;-) > Is this a 100% repeatable hang, or is it some occasional race? > 100% repeatable. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver model/scsi: synchronize pm calls with probe/remove
Hi, Dmitry. Dmitry Torokhov wrote: On Mon, 21 Mar 2005 18:18:46 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: Hello, Dmitry, Mochel and James. I've been looking at sd code and found seemingly bogus 'if (!sdkp)' tests with /* this can happen */ comment. I've digged changelog and found out that this was to prevent oops which occurs if some driver gets stuck inside ->probe and the machine goes down and calls back ->remove. IMHO, we should avoid this problem by fixing driver ->probe or ->remove callbacks instead of detecting and bypassing half-initialized/destroyed devices in pm callbacks. This patch read-locks a device's bus using device_pm_down_read_bus() before invoking any pm callback. Hi Tejun, There are talks about getting rid of bus's rwsem and replacing it with a per-device semaphore to serialize probe, remove, suspend and resume. This should resolve entire host of problems including this one, if I unrerstand it correctly. Please take a look here: http://seclists.org/lists/linux-kernel/2005/Mar/5847.html Yeap, sounds great. Hmmm.. as the final result will (and should) be the same for inidividual drivers (no overlapping callback invocations), how about incorporating my patch before implementing the proposed fix such that we can get rid of the awkward semantic first? The proposed change should change the same part of code anyway, so I don't think this would be a hassle. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 07:53:15PM -0500, Jon Smirl wrote: > Here is fedora's initrd nash script from my system. I modified it with > the sleep lines. > > It already is creating the /dev node with 'mkrootdev /dev/root' > I don't think udev is even running yet. Something else is causing this. > > echo "Loading libata.ko module" > insmod /lib/libata.ko > echo "Loading ata_piix.ko module" > insmod /lib/ata_piix.ko > echo "Loading raid1.ko module" > insmod /lib/raid1.ko > /sbin/udevstart > raidautorun /dev/md0 > >>>echo Sleep 1 > >>>sleep 1 > echo Creating root device > mkrootdev /dev/root > umount /sys Care to look at what mkrootdev does? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 08:14:29PM -0500, Kyle Moffett wrote: > On Mar 21, 2005, at 19:19, Andrew Morton wrote: > >Jon Smirl <[EMAIL PROTECTED]> wrote: > >>Jens is right that this is a user space issue, but how many people are > >>going to find this out the hard way when their root drives stop > >>mounting. Since no one is complaining I have to assume that most > >>kernel developers have their root device drivers built into the > >>kernel. I was loading mine as a module since for a long time Redhat > >>was not shipping kernels with SATA built in. > > > >I don't agree that this is a userspace issue. It's just not sane for a > >driver to be in an unusable state for an arbitrary length of time after > >modprobe returns. > > What about if I'm booting from a USB drive? That's a different issue, as you stated. There are other patches floating around that address this. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel bug: futex_wait hang
Andrew Morton wrote: > iirc we ended up deciding that the futex problems around that time were due > to userspace problems (a version of libc). But then, there's no discussion > around Seto's patch and it didn't get applied. So I don't know what > happened to that work - it's all a bit mysterious. It can be fixed _either_ in Glibc, or by changing the kernel. That problem is caused by differing assumptions between Glibc and the kernel about subtle futex semantics. Which goes to show they are really clever, or something. I provided pseudo-code for the Glibc fix, but not an actual patch because NPTL is quite complicated and I wanted to know the Glibc people were interested, but apparently they were too busy at the time - benchmarks would have made sense for such a patch. Scott Snyder started fixing part of Glibc, and that did fix his instance of this problem so we know the approach works. But a full patch for Glibc was not prepared. The most recent messages under "Futex queue_me/get_user ordering", with a patch from Jakub Jelinek will fix this problem by changing the kernel. Yes, you should apply Jakub's most recent patch, message-ID "<[EMAIL PROTECTED]>". I have not tested the patch, but it looks convincing. I argued for fixing Glibc on the grounds that the changed kernel behaviour, or more exactly having Glibc depend on it, loses a certain semantic property useful for unusual operations on multiple futexes at the same time. But I appear to have lost the argument, and Jakub's latest patch does clean up some cruft quite nicely, with no expected performance hit. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel bug: futex_wait hang
Lee Revell wrote:
> > iirc we ended up deciding that the futex problems around that time were due
> > to userspace problems (a version of libc). But then, there's no discussion
> > around Seto's patch and it didn't get applied. So I don't know what
> > happened to that work - it's all a bit mysterious.
>
> It does seem like it could be a different problem. Maybe Paul can
> provide some more evidence that it's a kernel and not a glibc/NPTL bug.
> I'm really just posting this on Paul's behalf; I don't claim to
> understand the issue. ;-)
Try applying the patch below, which was recently posted by Jakub Jelinek.
If it fixes the problem, it's the same thing as Hidetoshi Seto
noticed, although this patch is much improved thanks to
"preempt_count technology" (tm). If not, it's a whole new problem.
-- Jamie
--- linux-2.6.11/kernel/futex.c.jj 2005-03-17 04:42:29.0 -0500
+++ linux-2.6.11/kernel/futex.c 2005-03-18 05:45:29.0 -0500
@@ -97,7 +97,6 @@ struct futex_q {
*/
struct futex_hash_bucket {
spinlock_t lock;
- unsigned intnqueued;
struct list_head chain;
};
@@ -265,7 +264,6 @@ static inline int get_futex_value_locked
inc_preempt_count();
ret = __copy_from_user_inatomic(dest, from, sizeof(int));
dec_preempt_count();
- preempt_check_resched();
return ret ? -EFAULT : 0;
}
@@ -339,7 +337,6 @@ static int futex_requeue(unsigned long u
struct list_head *head1;
struct futex_q *this, *next;
int ret, drop_count = 0;
- unsigned int nqueued;
retry:
down_read(>mm->mmap_sem);
@@ -354,23 +351,22 @@ static int futex_requeue(unsigned long u
bh1 = hash_futex();
bh2 = hash_futex();
- nqueued = bh1->nqueued;
+ if (bh1 < bh2)
+ spin_lock(>lock);
+ spin_lock(>lock);
+ if (bh1 > bh2)
+ spin_lock(>lock);
+
if (likely(valp != NULL)) {
int curval;
- /* In order to avoid doing get_user while
- holding bh1->lock and bh2->lock, nqueued
- (monotonically increasing field) must be first
- read, then *uaddr1 fetched from userland and
- after acquiring lock nqueued field compared with
- the stored value. The smp_mb () below
- makes sure that bh1->nqueued is read from memory
- before *uaddr1. */
- smp_mb();
-
ret = get_futex_value_locked(, (int __user *)uaddr1);
if (unlikely(ret)) {
+ spin_unlock(>lock);
+ if (bh1 != bh2)
+ spin_unlock(>lock);
+
/* If we would have faulted, release mmap_sem, fault
* it in and start all over again.
*/
@@ -385,21 +381,10 @@ static int futex_requeue(unsigned long u
}
if (curval != *valp) {
ret = -EAGAIN;
- goto out;
+ goto out_unlock;
}
}
- if (bh1 < bh2)
- spin_lock(>lock);
- spin_lock(>lock);
- if (bh1 > bh2)
- spin_lock(>lock);
-
- if (unlikely(nqueued != bh1->nqueued && valp != NULL)) {
- ret = -EAGAIN;
- goto out_unlock;
- }
-
head1 = >chain;
list_for_each_entry_safe(this, next, head1, list) {
if (!match_futex (>key, ))
@@ -435,13 +420,9 @@ out:
return ret;
}
-/*
- * queue_me and unqueue_me must be called as a pair, each
- * exactly once. They are called with the hashed spinlock held.
- */
-
/* The key must be already stored in q->key. */
-static void queue_me(struct futex_q *q, int fd, struct file *filp)
+static inline struct futex_hash_bucket *
+queue_lock(struct futex_q *q, int fd, struct file *filp)
{
struct futex_hash_bucket *bh;
@@ -455,11 +436,35 @@ static void queue_me(struct futex_q *q,
q->lock_ptr = >lock;
spin_lock(>lock);
- bh->nqueued++;
+ return bh;
+}
+
+static inline void __queue_me(struct futex_q *q, struct futex_hash_bucket *bh)
+{
list_add_tail(>list, >chain);
spin_unlock(>lock);
}
+static inline void
+queue_unlock(struct futex_q *q, struct futex_hash_bucket *bh)
+{
+ spin_unlock(>lock);
+ drop_key_refs(>key);
+}
+
+/*
+ * queue_me and unqueue_me must be called as a pair, each
+ * exactly once. They are called with the hashed spinlock held.
+ */
+
+/* The key must be already stored in q->key. */
+static void queue_me(struct futex_q *q, int fd, struct file *filp)
+{
+ struct futex_hash_bucket *bh;
+ bh = queue_lock(q, fd, filp);
+ __queue_me(q, bh);
+}
+
/* Return 1 if we were still queued (ie. 0 means we were woken) */
static int unqueue_me(struct futex_q *q)
{
@@
Re: 2.6.12-rc1-mm1
Hi, Oleg Nesterov wrote: x86: fix ESP corruption CPU bug (take 2) I think that Stas tries to steal 1024 bytes from kernel's memory ... I think so too, sorry. I simply copied that from the cpu_gdt_table definition, and here's the mistake :( Probably this: --- $ nm -g vmlinux |grep cpu_gdt_table c02d7000 D cpu_gdt_table c037c300 D per_cpu__cpu_gdt_table --- can be optimized too? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Andrew Morton wrote: Josh Boyer <[EMAIL PROTECTED]> wrote: This is a useful, stable, and _maintained_ filesystem and I'm a bit surprised that there is this much resistance to it's inclusion. Although I've only been following things with half an eye, I don't think there's a lot of resistance. It's just that squashfs's proponents are being asked to explain the reasons why the kernel needs this filesystem. That's something into which no effort was made in the initial patch release (there's a lesson there). That is my fault. When I did the patch I was concentrating on providing code not on "selling" the filesystem. This is probably a cultural thing, coming from Britain, I actually thought such "strong arm" sales tatics would be tasteless and inappropropriate. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote: > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: > > > From: [EMAIL PROTECTED] > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic > > when loading the EMU10K1 driver > > > > > > > This one is a real mystery. No one can reproduce it. > > OK. But we don't seem to have heard from the originator since March 5th. > > > > From: [EMAIL PROTECTED] > > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 > > and > > > > > > > This one is fixed in ALSA CVS. > > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff > propagate from ALSA CVS into bk? > > The ALSA maintainers periodically ask Linus to pull from the linux-sound tree. But that's just the general "ALSA update" process. I'm not aware of a mechanism for getting critical fixes like this in ASAP. The last few have been shepherded through manually by various people. Looks like we need a better system. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 07:57:04PM -0500, Jon Smirl wrote: > On Mon, 21 Mar 2005 16:49:36 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > > Jon, what distro are you using? > > Up2date Fedore Core 3 Ok, sounds like a distro issue, try filing a bug in their bugzilla :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
On Mon, 2005-03-21 at 20:23 -0800, Andrew Morton wrote: > Lee Revell <[EMAIL PROTECTED]> wrote: > > I'm not aware of a mechanism for getting critical fixes like this in > > ASAP. The last few have been shepherded through manually by various > > people. Looks like we need a better system. > > > > It's not a trivial problem. > The linux-stable process seems to be working quite well so far. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clone() and pthread_create() segment fault in 2.4.29
On Mon, 21 Mar 2005 20:07:21 +0100, Arjan van de Ven said: > On Mon, Mar 21, 2005 at 11:54:10AM -0700, jmerkey wrote: > > which 2.4 kernels will work properly on RH ES release 3, Taroon Update 4. > > Only kernels with NPTL in, which for 2.4 limits you to the RH supplied one. Well, strictly speaking, it's all GPL'ed, so Jeff is certainly free to take the .src.rpm of the RedHat kernel, use rpm2cpio to extract the NPTL patches from it, and forward port it to the 2.4.NN of his choice... However, unless you're *really* handy with patch and diff, it's probably more productive to upgrade to RH EL release 4, which comes with a 2.6 kernel... (Speaking as somebody with RHEL 3 boxes going to RHEL 4 soon, and boxes that are 2.6-mm with Fedora patches on top.. both have their place in the greater scheme of things..) pgpscsiM847wi.pgp Description: PGP signature
Re: [patch 1/2] fork_connector: add a fork connector
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote: > On Mon, 2005-03-21 at 04:48, Guillaume Thouvenin wrote: > > ChangeLog: > > > > - Remove the global cn_fork_lock and replace it by a per CPU > > counter. > > - The processor ID has been added in the data part of the message. > > Thus datas sent in a message are: "CPU_ID PARENT_PID CHILD_PID" > > > > Those modifications were done to be more scalable because, as > > mentioned by Jesse Barnes, the global cn_fork_lock won't work well on a > > large CPU system. > > > > This patch applies to 2.6.11-mm4. > Guillaume, > > If a bunch of applications are listening for fork events, > your patch allows any application to turn off the > fork event notification? Is this the right behavior? > > Should'nt it turn off the fork-event notification when > the number of listeners become zero? There is no number of listeners - netlink sockets provide multicast dataflow. [Although one can obtain that number]. As far as I can see, Guillaume's application is main management utility - it can turn on or off some feature, like "ip" can turn on or off interfaces without waiting when bounded processes decide to exit. > RP -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
RE: Distinguish real vs. virtual CPUs?
>This is 2xXeonHT, is, 4 cpus on 2 packages: > >cat /proc/cpuinfo: > >processor : 0 >... >physical id: 0 >siblings : 2 >core id: 0 >cpu cores : 1 > >processor : 1 >... >physical id: 0 >siblings : 2 >core id: 0 >cpu cores : 1 > >processor : 2 >... >physical id: 3 >siblings : 2 >core id: 3 >cpu cores : 1 > >processor : 3 >... >physical id: 3 >siblings : 2 >core id: 3 >cpu cores : 1 > >So something like: > >cat /proc/cpuinfo | grep 'core id' | uniq | wc -l > >would give you the number of packages or 'real cpus'. Then you have to >choose which ones are unrelated. Usually evens are siblings of >odds, but >I won't trust on it... > Number of unique physical id will tell you the number of physical CPU packages in the system. Number of unique core id will tell you the total number of CPU cores in the system. Number of processor will tell you the total number of logical CPUs on the system. Then to find out the matching pairs, - to pair up all HT siblings on a core: Processors that have same "core id" are HT siblings in a core. - to pair up all CPUs in a package: Processors that have same "physical id" are all the CPUs belonging to the same physical package. Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel bug: futex_wait hang
Lee Revell <[EMAIL PROTECTED]> wrote: > > Paul Davis and Chris Morgan have been chasing down a problem with > xmms_jack and it really looks like this bug, thought to have been fixed > in 2.6.10, is the culprit. > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.0/2044.html > > (for more info google "futex_wait 2.6 hang") > > It's simple to reproduce. Run JACK and launch xmms with the JACK output > plugin. Close XMMS. The xmms process hangs. Strace looks like this: > > [EMAIL PROTECTED]:~$ strace -p 7935 > Process 7935 attached - interrupt to quit > futex(0xb5341bf8, FUTEX_WAIT, 7939, NULL > > Just like in the above bug report, if xmms is run with > LD_ASSUME_KERNEL=2.4.19, it works perfectly. > > I have reproduced the bug with 2.6.12-rc1. > iirc we ended up deciding that the futex problems around that time were due to userspace problems (a version of libc). But then, there's no discussion around Seto's patch and it didn't get applied. So I don't know what happened to that work - it's all a bit mysterious. Is this a 100% repeatable hang, or is it some occasional race? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> wrote: > > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > Herbert tells me that this might be fixed in 2.6.11. Did you try that? > > > > Nope. I'll try that. > > Did it work? Oops, sorry I didn't get back. Yes. It works fine in 2.6.11.3 Thanks a lot for the help. -- greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.11.2 1/1] PCI Allow OutOfRange PIRQ table address
Hi Greg, PCI folk,
I updated this to remove unnecessary variable initialization, make
check_routing be inline only and not __init, switch to strtoul, and
formatting fixes as per Randy Dunlap's recommendations.
I updated this to change pirq_table_addr to a long, and to add a warning
msg if the PIRQ table wasn't found at the specified address, as per thread
with Matthew Wilcox.
In our hardware situation, the BIOS is unable to store or generate it's PIRQ
table in the Fh-10h standard range. This patch adds a pci kernel
parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform
the kernel where the PIRQ table got stored. A beneficial side-effect is that,
if one's BIOS uses a static address each time for it's PIRQ table, then
pirqaddr can be used to avoid the $pirq search through that address block each
time at boot for normal PIRQ BIOSes.
---
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/common.c
linux-2.6.11.2/arch/i386/pci/common.c
--- linux-2.6.11.2-vanilla/arch/i386/pci/common.c 2005-03-10
16:31:25.0 +0800
+++ linux-2.6.11.2/arch/i386/pci/common.c 2005-03-17 14:25:54.23816
+0800
@@ -25,7 +25,8 @@ unsigned int pci_probe = PCI_PROBE_BIOS
int pci_routeirq;
int pcibios_last_bus = -1;
-struct pci_bus *pci_root_bus = NULL;
+unsigned long pirq_table_addr;
+struct pci_bus *pci_root_bus;
struct pci_raw_ops *raw_pci_ops;
static int pci_read(struct pci_bus *bus, unsigned int devfn, int where, int
size, u32 *value)
@@ -188,6 +189,9 @@ char * __devinit pcibios_setup(char *st
} else if (!strcmp(str, "biosirq")) {
pci_probe |= PCI_BIOS_IRQ_SCAN;
return NULL;
+ } else if (!strncmp(str, "pirqaddr=", 9)) {
+ pirq_table_addr = simple_strtoul(str+9, NULL, 0);
+ return NULL;
}
#endif
#ifdef CONFIG_PCI_DIRECT
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/irq.c
linux-2.6.11.2/arch/i386/pci/irq.c
--- linux-2.6.11.2-vanilla/arch/i386/pci/irq.c 2005-03-10 16:31:25.0
+0800
+++ linux-2.6.11.2/arch/i386/pci/irq.c 2005-03-17 14:04:22.0 +0800
@@ -58,6 +58,35 @@ struct irq_router_handler {
int (*pcibios_enable_irq)(struct pci_dev *dev) = NULL;
/*
+ * Check passed address for the PCI IRQ Routing Table signature
+ * and perform checksum verification.
+ */
+
+static inline struct irq_routing_table * pirq_check_routing_table(u8 *addr)
+{
+ struct irq_routing_table *rt;
+ int i;
+ u8 sum;
+
+ rt = (struct irq_routing_table *) addr;
+ if (rt->signature != PIRQ_SIGNATURE ||
+ rt->version != PIRQ_VERSION ||
+ rt->size % 16 ||
+ rt->size < sizeof(struct irq_routing_table))
+ return NULL;
+ sum = 0;
+ for (i=0; i < rt->size; i++)
+ sum += addr[i];
+ if (!sum) {
+ DBG("PCI: Interrupt Routing Table found at 0x%p\n", rt);
+ return rt;
+ }
+ return NULL;
+}
+
+
+
+/*
* Search 0xf -- 0xf for the PCI IRQ Routing Table.
*/
@@ -65,23 +94,17 @@ static struct irq_routing_table * __init
{
u8 *addr;
struct irq_routing_table *rt;
- int i;
- u8 sum;
+ if (pirq_table_addr) {
+ rt = pirq_check_routing_table((u8 *) __va(pirq_table_addr));
+ if (rt)
+ return rt;
+ printk(KERN_WARNING "PCI: PIRQ table NOT found at pirqaddr\n");
+ }
for(addr = (u8 *) __va(0xf); addr < (u8 *) __va(0x10); addr +=
16) {
- rt = (struct irq_routing_table *) addr;
- if (rt->signature != PIRQ_SIGNATURE ||
- rt->version != PIRQ_VERSION ||
- rt->size % 16 ||
- rt->size < sizeof(struct irq_routing_table))
- continue;
- sum = 0;
- for(i=0; isize; i++)
- sum += addr[i];
- if (!sum) {
- DBG("PCI: Interrupt Routing Table found at 0x%p\n", rt);
+ rt = pirq_check_routing_table(addr);
+ if (rt)
return rt;
- }
}
return NULL;
}
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/pci/pci.h
linux-2.6.11.2/arch/i386/pci/pci.h
--- linux-2.6.11.2-vanilla/arch/i386/pci/pci.h 2005-03-10 16:31:25.0
+0800
+++ linux-2.6.11.2/arch/i386/pci/pci.h 2005-03-17 08:54:36.0 +0800
@@ -27,6 +27,7 @@
#define PCI_ASSIGN_ALL_BUSSES 0x4000
extern unsigned int pci_probe;
+extern unsigned long pirq_table_addr;
/* pci-i386.c */
diff -uprN -X dontdiff
linux-2.6.11.2-vanilla/Documentation/kernel-parameters.txt
linux-2.6.11.2/Documentation/kernel-parameters.txt
--- linux-2.6.11.2-vanilla/Documentation/kernel-parameters.txt 2005-03-10
16:31:44.0 +0800
+++
Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell <[EMAIL PROTECTED]> wrote: > > On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote: > > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: > > > > From: [EMAIL PROTECTED] > > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic > > > when loading the EMU10K1 driver > > > > > > > > > > This one is a real mystery. No one can reproduce it. > > > > OK. But we don't seem to have heard from the originator since March 5th. > > > > > > From: [EMAIL PROTECTED] > > > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 > > > and > > > > > > > > > > This one is fixed in ALSA CVS. > > > > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff > > propagate from ALSA CVS into bk? > > > > > > The ALSA maintainers periodically ask Linus to pull from the linux-sound > tree. But that's just the general "ALSA update" process. Oh. I was always under the impression that http://linux-sound.bkbits.net/linux-sound contains the latest devel stuff for -mm. > I'm not aware of a mechanism for getting critical fixes like this in > ASAP. The last few have been shepherded through manually by various > people. Looks like we need a better system. > It's not a trivial problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell <[EMAIL PROTECTED]> wrote: > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: > > From: [EMAIL PROTECTED] > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when > loading the EMU10K1 driver > > > > This one is a real mystery. No one can reproduce it. OK. But we don't seem to have heard from the originator since March 5th. > > From: [EMAIL PROTECTED] > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and > > > > This one is fixed in ALSA CVS. But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff propagate from ALSA CVS into bk? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
unable to handle paging request in worker_thread on apm resume
I got the following after an apm resume on a thinkpad X31, with 2.6.12-rc1 plus some (hopefully unrelated) NFS patches. Any ideas? --Bruce Fields Mar 21 18:22:44 puzzle apmd[1815]: Suspending now Mar 21 22:37:36 puzzle kernel: PCI: Setting latency timer of device :00:1d.0 to 64 Mar 21 22:37:36 puzzle kernel: PCI: Setting latency timer of device :00:1d.1 to 64 Mar 21 22:37:36 puzzle kernel: PCI: Setting latency timer of device :00:1d.2 to 64 Mar 21 22:37:39 puzzle kernel: Unable to handle kernel paging request at virtual address d28c9dbc Mar 21 22:37:39 puzzle kernel: printing eip: Mar 21 22:37:39 puzzle kernel: c01331a6 Mar 21 22:37:39 puzzle kernel: *pde = 00048067 Mar 21 22:37:39 puzzle kernel: *pte = 128c9000 Mar 21 22:37:39 puzzle kernel: Oops: 0002 [#1] Mar 21 22:37:39 puzzle kernel: PREEMPT DEBUG_PAGEALLOC Mar 21 22:37:39 puzzle kernel: Modules linked in: Mar 21 22:37:39 puzzle kernel: CPU:0 Mar 21 22:37:39 puzzle kernel: EIP:0060:[]Not tainted VLI Mar 21 22:37:39 puzzle kernel: EFLAGS: 00010093 (2.6.12-rc1-CITI_NFS4_ALL-1) Mar 21 22:37:39 puzzle kernel: EIP is at worker_thread+0x1a6/0x400 Mar 21 22:37:39 puzzle kernel: eax: d28c9db8 ebx: 0246 ecx: c0680ea4 edx: dff19f58 Mar 21 22:37:39 puzzle kernel: esi: dff19f38 edi: c0680ea0 ebp: dff0ffc4 esp: dff0ff5c Mar 21 22:37:39 puzzle kernel: ds: 007b es: 007b ss: 0068 Mar 21 22:37:39 puzzle kernel: Process events/0 (pid: 3, threadinfo=dff0f000 task=dff1aa90) Mar 21 22:37:39 puzzle kernel: Stack: dff19f80 c05643e0 dff0f000 dff19f58 0001 Mar 21 22:37:39 puzzle kernel: c0115ec0 0001 dff07e44 c0571eff dff0ffc8 Mar 21 22:37:39 puzzle kernel:dff1aa90 c0115ec0 00100100 00200200 e1b0835a dff1aa90 dff0f000 Mar 21 22:37:39 puzzle kernel: Call Trace: Mar 21 22:37:39 puzzle kernel: [] show_stack+0x75/0x90 Mar 21 22:37:39 puzzle kernel: [] show_registers+0x11b/0x180 Mar 21 22:37:39 puzzle kernel: [] die+0x13d/0x290 Mar 21 22:37:39 puzzle kernel: [] do_page_fault+0x30f/0x68e Mar 21 22:37:39 puzzle kernel: [] error_code+0x2b/0x30 Mar 21 22:37:39 puzzle kernel: [] kthread+0x98/0xa0 Mar 21 22:37:39 puzzle kernel: [] kernel_thread_helper+0x5/0xc Mar 21 22:37:39 puzzle kernel: Code: 00 8b 4e 20 3b 4d a8 0f 84 0a 01 00 00 8d 56 48 89 55 98 89 f6 8d 79 fc 8b 47 0c 89 45 a0 8b 57 10 89 55 9c 8b 51 04 8b 01 89 02 <89> 50 04 89 09 89 49 04 81 3e 3c 4b 24 1d 74 18 56 68 a8 00 00 Mar 21 22:37:39 puzzle kernel: <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 Mar 21 22:37:39 puzzle kernel: in_atomic():1, irqs_disabled():0 Mar 21 22:37:39 puzzle kernel: [] dump_stack+0x17/0x20 Mar 21 22:37:39 puzzle kernel: [] __might_sleep+0x99/0xb0 Mar 21 22:37:39 puzzle kernel: [] profile_task_exit+0x15/0x50 Mar 21 22:37:39 puzzle kernel: [] do_exit+0x1a/0x760 Mar 21 22:37:39 puzzle kernel: [] die+0x288/0x290 Mar 21 22:37:39 puzzle kernel: [] do_page_fault+0x30f/0x68e Mar 21 22:37:39 puzzle kernel: [] error_code+0x2b/0x30 Mar 21 22:37:39 puzzle kernel: [] kthread+0x98/0xa0 Mar 21 22:37:39 puzzle kernel: [] kernel_thread_helper+0x5/0xc Mar 21 22:37:39 puzzle kernel: note: events/0[3] exited with preempt_count 1 Mar 21 22:37:39 puzzle kernel: PCI: cache line size of 32 is not supported by device :00:1d.7 Mar 21 22:37:39 puzzle kernel: ehci_hcd :00:1d.7: USB 2.0 restarted, EHCI 1.00, driver 10 Dec 2004 Mar 21 22:37:39 puzzle kernel: PCI: Found IRQ 11 for device :00:1f.1 Mar 21 22:37:39 puzzle kernel: PCI: Sharing IRQ 11 with :00:1d.2 Mar 21 22:37:39 puzzle kernel: PCI: Sharing IRQ 11 with :02:00.2 Mar 21 22:37:39 puzzle kernel: PCI: Sharing IRQ 11 with :02:02.0 Mar 21 22:37:39 puzzle kernel: PCI: Found IRQ 11 for device :00:1f.5 Mar 21 22:37:39 puzzle kernel: PCI: Sharing IRQ 11 with :00:1f.3 Mar 21 22:37:39 puzzle kernel: PCI: Sharing IRQ 11 with :00:1f.6 Mar 21 22:37:39 puzzle kernel: PCI: Sharing IRQ 11 with :02:00.1 Mar 21 22:37:39 puzzle kernel: PCI: Setting latency timer of device :00:1f.5 to 64 Mar 21 22:37:40 puzzle kernel: PCI: Found IRQ 11 for device :01:00.0 Mar 21 22:37:40 puzzle kernel: PCI: Sharing IRQ 11 with :00:1d.0 Mar 21 22:37:40 puzzle kernel: PCI: Sharing IRQ 11 with :02:00.0 Mar 21 22:37:40 puzzle kernel: PCI: Found IRQ 11 for device :02:00.2 Mar 21 22:37:40 puzzle kernel: PCI: Sharing IRQ 11 with :00:1d.2 Mar 21 22:37:40 puzzle kernel: PCI: Sharing IRQ 11 with :00:1f.1 Mar 21 22:37:40 puzzle kernel: PCI: Sharing IRQ 11 with :02:02.0 Mar 21 22:37:41 puzzle kernel: PCI: Found IRQ 11 for device :02:08.0 Mar 21 22:37:41 puzzle kernel: kernel/workqueue.c:82: spin_lock(kernel/workqueue.c:dff19f38) already locked by kernel/workqueue.c/174 Mar 21 22:37:41 puzzle kernel: agpgart: Found an AGP 2.0 compliant device at :00:00.0. Mar 21 22:37:41 puzzle kernel: agpgart: Putting AGP V2 device at
[DVB patch 07/48] skystar2: update email address
Updated email address. Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> skystar2.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/b2c2/skystar2.c === --- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/b2c2/skystar2.c 2005-03-22 00:14:40.0 +0100 +++ linux-2.6.12-rc1-mm1/drivers/media/dvb/b2c2/skystar2.c 2005-03-22 00:14:55.0 +0100 @@ -5,14 +5,14 @@ * Copyright (C) 2003 Vadim Catana, [EMAIL PROTECTED] * * FIX: DISEQC Tone Burst in flexcop_diseqc_ioctl() - * FIX: FULL soft DiSEqC for skystar2 (FlexCopII rev 130) VP310 equipped + * FIX: FULL soft DiSEqC for skystar2 (FlexCopII rev 130) VP310 equipped * Vincenzo Di Massa, hawk.it at tiscalinet.it - * + * * Converted to Linux coding style * Misc reorganization, polishing, restyling - * Roberto Ragusa, r.ragusa at libero.it - * - * Added hardware filtering support, + * Roberto Ragusa, skystar2-c5b8 at robertoragusa dot it + * + * Added hardware filtering support, * Niklas Peinecke, peinecke at gdv.uni-hannover.de * * -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 13/48] dib3000: corrected device naming
corrected device naming (Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
Kconfig |4 ++--
dib3000-common.c |2 +-
dib3000-common.h |8
dib3000.h|2 +-
dib3000mb.c |6 +++---
dib3000mc.c | 10 +-
dib3000mc_priv.h |2 +-
7 files changed, 17 insertions(+), 17 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/Kconfig
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/Kconfig
2005-03-22 00:15:13.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/Kconfig2005-03-22
00:15:24.0 +0100
@@ -108,14 +108,14 @@ config DVB_MT352
A DVB-T tuner module. Say Y when you want to support this frontend.
config DVB_DIB3000MB
- tristate "DiBcom 3000-MB"
+ tristate "DiBcom 3000M-B"
depends on DVB_CORE
help
A DVB-T tuner module. Designed for mobile usage. Say Y when you want
to support this frontend.
config DVB_DIB3000MC
- tristate "DiBcom 3000-MC/P"
+ tristate "DiBcom 3000P/M-C"
depends on DVB_CORE
help
A DVB-T tuner module. Designed for mobile usage. Say Y when you want
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000-common.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/dib3000-common.c
2005-03-21 23:27:58.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000-common.c
2005-03-22 00:15:24.0 +0100
@@ -73,7 +73,7 @@ u16 dib3000_seq[2][2][2] = /* fft,gu
};
MODULE_AUTHOR("Patrick Boettcher <[EMAIL PROTECTED]");
-MODULE_DESCRIPTION("Common functions for the dib3000mb/dib3000mc dvb frontend
drivers");
+MODULE_DESCRIPTION("Common functions for the dib3000mb/dib3000mc dvb-frontend
drivers");
MODULE_LICENSE("GPL");
EXPORT_SYMBOL(dib3000_seq);
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000-common.h
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/dib3000-common.h
2005-03-21 23:27:58.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000-common.h
2005-03-22 00:15:24.0 +0100
@@ -1,6 +1,6 @@
/*
* .h-files for the common use of the frontend drivers made by DiBcom
- * DiBcom 3000-MB/MC/P
+ * DiBcom 3000M-B/C, 3000P
*
* DiBcom (http://www.dibcom.fr/)
*
@@ -30,9 +30,9 @@
#include "dib3000.h"
/* info and err, taken from usb.h, if there is anything available like by
default. */
-#define err(format, arg...) printk(KERN_ERR "dib3000mX: " format "\n" , ## arg)
-#define info(format, arg...) printk(KERN_INFO "dib3000mX: " format "\n" , ##
arg)
-#define warn(format, arg...) printk(KERN_WARNING "dib3000mX: " format "\n" ,
## arg)
+#define err(format, arg...) printk(KERN_ERR "dib3000: " format "\n" , ##
arg)
+#define info(format, arg...) printk(KERN_INFO"dib3000: " format "\n" , ##
arg)
+#define warn(format, arg...) printk(KERN_WARNING "dib3000: " format "\n" , ##
arg)
/* frontend state */
struct dib3000_state {
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000.h
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/dib3000.h
2005-03-21 23:27:58.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000.h 2005-03-22
00:15:24.0 +0100
@@ -1,6 +1,6 @@
/*
* public header file of the frontend drivers for mobile DVB-T demodulators
- * DiBcom 3000-MB and DiBcom 3000-MC/P (http://www.dibcom.fr/)
+ * DiBcom 3000M-B and DiBcom 3000P/M-C (http://www.dibcom.fr/)
*
* Copyright (C) 2004-5 Patrick Boettcher ([EMAIL PROTECTED])
*
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000mb.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/dib3000mb.c
2005-03-22 00:14:30.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/dib3000mb.c
2005-03-22 00:15:24.0 +0100
@@ -1,5 +1,5 @@
/*
- * Frontend driver for mobile DVB-T demodulator DiBcom 3000-MB
+ * Frontend driver for mobile DVB-T demodulator DiBcom 3000M-B
* DiBcom (http://www.dibcom.fr/)
*
* Copyright (C) 2004-5 Patrick Boettcher ([EMAIL PROTECTED])
@@ -35,7 +35,7 @@
/* Version information */
#define DRIVER_VERSION "0.1"
-#define DRIVER_DESC "DiBcom 3000M-B DVB-T demodulator driver"
+#define DRIVER_DESC "DiBcom 3000M-B DVB-T demodulator"
#define DRIVER_AUTHOR "Patrick Boettcher, [EMAIL PROTECTED]"
#ifdef CONFIG_DVB_DIBCOM_DEBUG
@@ -745,7 +745,7 @@ error:
static struct dvb_frontend_ops dib3000mb_ops = {
.info = {
- .name = "DiBcom 3000-MB DVB-T",
+ .name
[DVB patch 11/48] nxt2002: QAM64/256 support
patch by Taylor Jacob: Add QAM64/256 Support
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
Kconfig |1 +
nxt2002.c | 43 +--
2 files changed, 42 insertions(+), 2 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/nxt2002.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/nxt2002.c
2005-03-22 00:14:18.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/nxt2002.c 2005-03-22
00:15:13.0 +0100
@@ -343,8 +343,21 @@ static int nxt2002_setup_frontend_parame
/* reset the agc now that tuning has been completed */
nxt2002_agc_reset(state);
+
+
/* set target power level */
+ switch (p->u.vsb.modulation) {
+ case QAM_64:
+ case QAM_256:
+ buf[0] = 0x74;
+ break;
+ case VSB_8:
buf[0] = 0x70;
+ break;
+ default:
+ return -EINVAL;
+ break;
+ }
i2c_writebytes(state,0x42,buf,1);
/* configure sdm */
@@ -357,7 +370,20 @@ static int nxt2002_setup_frontend_parame
nxt2002_writereg_multibyte(state,0x58,buf,2);
/* write sdmx input */
+ switch (p->u.vsb.modulation) {
+ case QAM_64:
+ buf[0] = 0x68;
+ break;
+ case QAM_256:
+ buf[0] = 0x64;
+ break;
+ case VSB_8:
buf[0] = 0x60;
+ break;
+ default:
+ return -EINVAL;
+ break;
+ }
buf[1] = 0x00;
nxt2002_writereg_multibyte(state,0x5C,buf,2);
@@ -387,7 +413,20 @@ static int nxt2002_setup_frontend_parame
i2c_writebytes(state,0x41,buf,1);
/* write agc ucgp0 */
+ switch (p->u.vsb.modulation) {
+ case QAM_64:
+ buf[0] = 0x02;
+ break;
+ case QAM_256:
+ buf[0] = 0x03;
+ break;
+ case VSB_8:
buf[0] = 0x00;
+ break;
+ default:
+ return -EINVAL;
+ break;
+ }
i2c_writebytes(state,0x30,buf,1);
/* write agc control reg */
@@ -632,12 +671,12 @@ static struct dvb_frontend_ops nxt2002_o
.name = "Nextwave nxt2002 VSB/QAM frontend",
.type = FE_ATSC,
.frequency_min = 5400,
- .frequency_max = 80300,
+ .frequency_max = 80600,
/* stepsize is just a guess */
.frequency_stepsize = 16,
.caps = FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
- FE_CAN_8VSB
+ FE_CAN_8VSB | FE_CAN_QAM_64 | FE_CAN_QAM_256
},
.release = nxt2002_release,
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/Kconfig
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/frontends/Kconfig
2005-03-21 23:27:58.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/frontends/Kconfig2005-03-22
00:15:13.0 +0100
@@ -154,6 +154,7 @@ comment "ATSC (North American/Korean Ter
config DVB_NXT2002
tristate "Nxt2002 based"
depends on DVB_CORE
+ select FW_LOADER
help
An ATSC 8VSB tuner module. Say Y when you want to support this
frontend.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 06/48] support Activy Budget card
support Activy Budget with ALPS BSRU6 tuner
submitted by Andreas 'randy' Weinberger.
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
budget.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/budget.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/ttpci/budget.c 2005-03-21
23:27:59.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/ttpci/budget.c 2005-03-22
00:14:50.0 +0100
@@ -444,9 +444,15 @@ static void frontend_init(struct budget
if (budget->dvb_frontend) break;
break;
- case 0x4f61: // Fujitsu Siemens Activy Budget-S PCI (tda8083/Grundig
29504-451(tsa5522))
+ case 0x4f60: // Fujitsu Siemens Activy Budget-S PCI rev AL
(stv0299/ALPS BSRU6(tsa5059))
+ budget->dvb_frontend = stv0299_attach(_bsru6_config,
>i2c_adap);
+ if (budget->dvb_frontend) {
+ budget->dvb_frontend->ops->set_voltage =
siemens_budget_set_voltage;
+ break;
+ }
+ break;
- // grundig 29504-451
+ case 0x4f61: // Fujitsu Siemens Activy Budget-S PCI rev GR
(tda8083/Grundig 29504-451(tsa5522))
budget->dvb_frontend =
tda8083_attach(_29504_451_config, >i2c_adap);
if (budget->dvb_frontend) {
budget->dvb_frontend->ops->set_voltage =
siemens_budget_set_voltage;
@@ -518,14 +524,16 @@ MAKE_BUDGET_INFO(ttbs,"TT-Budget/WinTV-
MAKE_BUDGET_INFO(ttbc, "TT-Budget/WinTV-NOVA-C PCI", BUDGET_TT);
MAKE_BUDGET_INFO(ttbt, "TT-Budget/WinTV-NOVA-T PCI", BUDGET_TT);
MAKE_BUDGET_INFO(satel,"SATELCO Multimedia PCI",
BUDGET_TT_HW_DISEQC);
-MAKE_BUDGET_INFO(fsacs, "Fujitsu Siemens Activy Budget-S PCI",
BUDGET_FS_ACTIVY);
+MAKE_BUDGET_INFO(fsacs0, "Fujitsu Siemens Activy Budget-S PCI (rev GR/grundig
frontend)", BUDGET_FS_ACTIVY);
+MAKE_BUDGET_INFO(fsacs1, "Fujitsu Siemens Activy Budget-S PCI (rev AL/alps
frontend)", BUDGET_FS_ACTIVY);
static struct pci_device_id pci_tbl[] = {
MAKE_EXTENSION_PCI(ttbs, 0x13c2, 0x1003),
MAKE_EXTENSION_PCI(ttbc, 0x13c2, 0x1004),
MAKE_EXTENSION_PCI(ttbt, 0x13c2, 0x1005),
MAKE_EXTENSION_PCI(satel, 0x13c2, 0x1013),
- MAKE_EXTENSION_PCI(fsacs, 0x1131, 0x4f61),
+ MAKE_EXTENSION_PCI(fsacs1,0x1131, 0x4f60),
+ MAKE_EXTENSION_PCI(fsacs0,0x1131, 0x4f61),
{
.vendor= 0,
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 03/48] dibusb: misc. fixes
o worked around hw_sleep handling for usb1.1 devices
o fixed oops when no frontend was attached (because of usb1.1 timeouts in my
debugging sessions)
(Patrick Boettcher)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvb-dibusb-fe-i2c.c |4 ++
dvb-dibusb-usb.c| 70 ++--
2 files changed, 39 insertions(+), 35 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
2005-03-21 23:27:59.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
2005-03-22 00:14:35.0 +0100
@@ -178,6 +178,8 @@ int dibusb_fe_init(struct usb_dibusb* di
break;
}
}
+ /* if a frontend was found */
+ if (dib->fe != NULL) {
if (dib->fe->ops->sleep != NULL)
dib->fe_sleep = dib->fe->ops->sleep;
dib->fe->ops->sleep = dibusb_hw_sleep;
@@ -192,6 +194,7 @@ int dibusb_fe_init(struct usb_dibusb* di
/* check which tuner is mounted on this device, in case
this is unsure */
dibusb_tuner_quirk(dib);
}
+ }
if (dib->fe == NULL) {
err("A frontend driver was not found for device '%s'.",
dib->dibdev->name);
@@ -205,6 +208,7 @@ int dibusb_fe_init(struct usb_dibusb* di
return -ENODEV;
}
}
+
return 0;
}
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-usb.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-usb.c
2005-03-21 23:27:59.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-usb.c
2005-03-22 00:14:35.0 +0100
@@ -1,12 +1,12 @@
/*
- * dvb-dibusb-usb.c is part of the driver for mobile USB Budget DVB-T devices
+ * dvb-dibusb-usb.c is part of the driver for mobile USB Budget DVB-T devices
* based on reference design made by DiBcom (http://www.dibcom.fr/)
*
* Copyright (C) 2004-5 Patrick Boettcher ([EMAIL PROTECTED])
*
* see dvb-dibusb-core.c for more copyright details.
*
- * This file contains functions for initializing and handling the
+ * This file contains functions for initializing and handling the
* usb specific stuff.
*/
#include "dvb-dibusb.h"
@@ -25,18 +25,18 @@ int dibusb_readwrite_usb(struct usb_dibu
if ((ret = down_interruptible(>usb_sem)))
return ret;
- if (dib->feedcount &&
- wbuf[0] == DIBUSB_REQ_I2C_WRITE &&
+ if (dib->feedcount &&
+ wbuf[0] == DIBUSB_REQ_I2C_WRITE &&
dib->dibdev->dev_cl->id == DIBUSB1_1)
deb_err("BUG: writing to i2c, while TS-streaming destroys the
stream."
"(%x reg: %x %x)\n", wbuf[0],wbuf[2],wbuf[3]);
-
+
debug_dump(wbuf,wlen);
ret = usb_bulk_msg(dib->udev,usb_sndbulkpipe(dib->udev,
dib->dibdev->dev_cl->pipe_cmd), wbuf,wlen,,
DIBUSB_I2C_TIMEOUT);
-
+
if (ret)
err("bulk message failed: %d (%d/%d)",ret,wlen,actlen);
else
@@ -55,7 +55,7 @@ int dibusb_readwrite_usb(struct usb_dibu
debug_dump(rbuf,actlen);
}
}
-
+
up(>usb_sem);
return ret;
}
@@ -63,15 +63,18 @@ int dibusb_readwrite_usb(struct usb_dibu
/*
* Cypress controls
*/
+static int dibusb_write_usb(struct usb_dibusb *dib, u8 *buf, u16 len)
+{
+ return dibusb_readwrite_usb(dib,buf,len,NULL,0);
+}
#if 0
-/*
- * #if 0'ing the following functions as they are not in use _now_,
+/*
+ * #if 0'ing the following functions as they are not in use _now_,
* but probably will be sometime.
*/
-
/*
- * do not use this, just a workaround for a bug,
+ * do not use this, just a workaround for a bug,
* which will hopefully never occur :).
*/
int dibusb_interrupt_read_loop(struct usb_dibusb *dib)
@@ -79,15 +82,10 @@ int dibusb_interrupt_read_loop(struct us
u8 b[1] = { DIBUSB_REQ_INTR_READ };
return dibusb_write_usb(dib,b,1);
}
-
-#endif
-static int dibusb_write_usb(struct usb_dibusb *dib, u8 *buf, u16 len)
-{
- return dibusb_readwrite_usb(dib,buf,len,NULL,0);
-}
+#endif
/*
- * ioctl for the firmware
+ * ioctl for the firmware
*/
static int dibusb_ioctl_cmd(struct usb_dibusb *dib, u8 cmd, u8 *param, int
plen)
{
@@ -112,10 +110,10 @@ int dibusb_hw_wakeup(struct dvb_frontend
u8 b[1] = { DIBUSB_IOCTL_POWER_WAKEUP };
deb_info("dibusb-device is getting up.\n");
[DVB patch 38/48] dibusb: remove useless ifdef
removed useless ifdef: dvb_register_adapter always takes 3 parameters in this
tree
(Andreas Oberritter)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
dvb-dibusb-dvb.c |6 +-
1 files changed, 1 insertion(+), 5 deletions(-)
Index: linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
===
--- linux-2.6.12-rc1-mm1.orig/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
2005-03-22 00:17:09.0 +0100
+++ linux-2.6.12-rc1-mm1/drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
2005-03-22 00:27:41.0 +0100
@@ -125,12 +125,8 @@ int dibusb_dvb_init(struct usb_dibusb *d
urb_compl_count = 0;
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,4)
-if ((ret = dvb_register_adapter(>adapter, DRIVER_DESC)) < 0) {
-#else
-if ((ret = dvb_register_adapter(>adapter, DRIVER_DESC ,
+ if ((ret = dvb_register_adapter(>adapter, DRIVER_DESC,
THIS_MODULE)) < 0) {
-#endif
deb_info("dvb_register_adapter failed: error %d", ret);
goto err;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] ext3 bug in ftruncate() with O_SYNC?
Ben Pfaff <[EMAIL PROTECTED]> wrote:
>
> Hi. We're doing some checking on Linux file systems and found
> what appears to be a bug in the Linux 2.6.11 implementation of
> ext3: when ftruncate shrinks a file, using a file descriptor
> opened with O_SYNC, the file size is not updated synchronously.
> I've appended a test program that illustrates the problem. After
> this program runs, the file system shows a file with length 1031,
> not 4 as would be expected if the ftruncate completed
> synchronously. (If I insert an fsync before closing the file,
> the file length is correct.)
>
> Does this look like a bug to you guys?
>
The spec says "Write I/O operations on the file descriptor shall complete
as defined by synchronized I/O file integrity completion".
Is ftruncate a "write I/O operation"? No. Should ftruncate() honour
O_SYNC? I'd say so, yes. After all, an extending ftruncate is a
sort-of-write.
Unfortunately Linux doesn't pass the file* down to the
filesytem's ->truncate() handler, so the fs doesn't know that the
ftruncated fd was opened O_SYNC. I don't think _any_ Linux filesystems get
this right.
> Ben.
>
> --
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define CHECK(ret) if(ret < 0) {perror(0); assert(0);}
>
> int systemf(const char *fmt, ...)
> {
> static char cmd[1024];
>
> va_list ap;
> va_start(ap, fmt);
> vsprintf(cmd, fmt, ap);
> va_end(ap);
>
> fprintf(stderr, "running cmd \"%s\"\n", cmd);
> return system(cmd);
> }
>
> main(int argc, char *argv[])
> {
> int ret, fd;
> systemf("umount /dev/sbd0");
> systemf("sbin/mkfs.ext3 -F -j -b 1024 /dev/sbd0 2048");
> systemf("sbin/e2fsck.shared -y /dev/sbd0");
> systemf("mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535");
> systemf("umount /dev/sbd0");
> systemf("mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535");
>
> fd = open("/mnt/sbd0/0001", O_CREAT | O_RDWR | O_SYNC, 0700);
> CHECK(fd);
> ret = write(fd, "foobar", 6);
> CHECK(ret);
> ret = ftruncate(fd, 1031);
> CHECK(ret);
> ret = pwrite(fd, "bazzle", 6, 1031 - 6);
> CHECK(ret);
> ret = ftruncate(fd, 4);
> CHECK(ret);
> ret = close(fd);
> CHECK(ret);
>
> #if 0
> {
> #include "../sbd/sbd.h"
> int sbd_fd = open("/dev/sbd0", O_RDONLY);
> ret = ioctl(sbd_fd, SBD_COPY_DISK, 1);
> CHECK(ret);
> close(sbd_fd);
> }
> #else
> systemf("reboot -f -n");
> #endif
> return 0;
> }
>
>
>
> --
> Ben Pfaff
> email: [EMAIL PROTECTED]
> web: http://benpfaff.org
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
