Re: Fw: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
On Sun, 16 Dec 2007 01:37:01 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
argh, please don't use linux-net. It's basically dead afaik.
Suitable ccs restored.
> > On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
> > >
> > > I suspect namespace borkage. But just because you pin-pointed
> > > my patch I'll try to track it down :)
> >
> > Surprise surprise. The namespace seq patch missed two spots in
> > AF_PACKET.
> >
> > [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
> >
> > The seq_open_net patch changed the meaning of seq->private.
> > Unfortunately it missed two spots in AF_PACKET, which still
> > used the old way of dereferencing seq->private, thus causing
> > weird and wonderful crashes when reading /proc/net/packet.
> >
> > This patch fixes them.
> >
> > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> >
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > index 485af56..43e49f4 100644
> > --- a/net/packet/af_packet.c
> > +++ b/net/packet/af_packet.c
> > @@ -1878,7 +1878,7 @@ static void *packet_seq_start(struct seq_file *seq,
> > loff_t *pos)
> >
> > static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> > {
> > - struct net *net = seq->private;
> > + struct net *net = seq_file_net(seq);
> > ++*pos;
> > return (v == SEQ_START_TOKEN)
> > ? sk_head(>packet.sklist)
> > @@ -1887,7 +1887,7 @@ static void *packet_seq_next(struct seq_file *seq,
> > void *v, loff_t *pos)
> >
> > static void packet_seq_stop(struct seq_file *seq, void *v)
> > {
> > - struct net *net = seq->private;
> > + struct net *net = seq_file_net(seq);
> > read_unlock(>packet.sklist_lock);
> > }
> >
>
> ...
>
>
> Hmm. I tried compiling again with this patch applied and lockdep
> turned back on, and got the following (I will try again with lockdep
> turned back off):
>
> Dec 15 13:44:39 syntropy kernel: process `cat' is using deprecated
> sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use
> net.ipv6.neigh.default.retrans_time_ms instead.
> Dec 15 13:44:39 syntropy kernel:
> Dec 15 13:44:39 syntropy kernel: =
> Dec 15 13:44:39 syntropy kernel: [ BUG: bad unlock balance detected! ]
> Dec 15 13:44:39 syntropy kernel: -
> Dec 15 13:44:39 syntropy kernel: cat/4819 is trying to release lock
> (kkkȦ) at:
> Dec 15 13:44:39 syntropy kernel: [packet_seq_stop+0xe/0x10]
> packet_seq_stop+0xe/0x10
> Dec 15 13:44:39 syntropy kernel: but there are no more locks to release!
> Dec 15 13:44:39 syntropy kernel:
> Dec 15 13:44:39 syntropy kernel: other info that might help us debug this:
> Dec 15 13:44:39 syntropy kernel: 2 locks held by cat/4819:
> Dec 15 13:44:39 syntropy kernel: #0: (>lock){--..}, at:
> [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
So your kernel is still feeding garbage into lockdep.
Are you really really sure that kernel had Herbert's patch applied?
--
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: dst cache overflow
On Sat, Dec 15, 2007 at 11:08:58AM +0100, Tobias Diedrich wrote:
>
> Hmm, how do I look for that, if netstat doesn't look suspicous?
Thanks. What does /proc/net/sockstat show?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: E6850 has an 8+ minute delay during boot
On Dec 15, 2007 1:07 AM, Len Brown <[EMAIL PROTECTED]> wrote: > > try CONFIG_HIGH_RES_TIMERS=n > try "hpet=disable" The problem still manifests when I unset CONFIG_HIGH_RES_TIMERS, CONFIG_HPET_TIMER, and CONFIG_NO_HZ (for good measure) in the kernel config. The delay occurs later in the bootup process now. Here's a dmesg snippet: [ 31.895755] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 31.896046] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 31.896203] TCP: Hash tables configured (established 131072 bind 65536) [ 31.896244] TCP reno registered [ 31.907674] checking if image is initramfs... it is [ 541.796307] Freeing initrd memory: 44299k freed [ 541.796748] audit: initializing netlink socket (disabled) [ 541.796798] audit(1197764951.576:1): initialized Thanks, Arun = Full dmesg: [0.00] Initializing cgroup subsys cpuset [0.00] Linux version 2.6.24-rc5 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #2 SMP Sat Dec 15 23:38:57 EST 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00099c00 (usable) [0.00] BIOS-e820: 00099c00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7fe9 (usable) [0.00] BIOS-e820: 7fe9 - 7fee3000 (ACPI NVS) [0.00] BIOS-e820: 7fee3000 - 7fef (ACPI data) [0.00] BIOS-e820: 7fef - 7ff0 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] 1150MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000f3f00 [0.00] Entering add_active_range(0, 0, 523920) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 229376 [0.00] HighMem229376 -> 523920 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 523920 [0.00] On node 0 totalpages: 523920 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 1760 pages used for memmap [0.00] Normal zone: 223520 pages, LIFO batch:31 [0.00] HighMem zone: 2301 pages used for memmap [0.00] HighMem zone: 292243 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.5 present. [0.00] ACPI: RSDP 000F97A0, 0024 (r2 DELL ) [0.00] ACPI: XSDT 7FEE3080, 005C (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: FACP 7FEE7200, 00F4 (r3 DELLFX0942302E31 AWRD0) [0.00] ACPI: DSDT 7FEE3200, 3FFC (r1 DELL AWRDACPI 1000 MSFT 300) [0.00] ACPI: FACS 7FE9, 0040 [0.00] ACPI: HPET 7FEE73C0, 0038 (r1 DELLFX0942302E31 AWRD 98) [0.00] ACPI: MCFG 7FEE7400, 003C (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: SLIC 7FEE7440, 0176 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: DMY2 7FEE75C0, 0080 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: APIC 7FEE7300, 0084 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: SSDT 7FEE7CA0, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 6:15 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 6:15 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating
Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Sat, 15 Dec 2007, Parag Warudkar wrote: I will run it for a little longer just to be sure - but I don't think it will be a problem. No problems for last 10 hours - I consider this fixed. Parag -- 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: [Bug 9182] Critical memory leak (dirty pages)
On Sun, 16 Dec 2007 00:08:52 +0100 (CET) Krzysztof Oledzki <[EMAIL PROTECTED]> wrote: > > > On Sat, 15 Dec 2007, [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=9182 > > > > > > --- Comment #33 from [EMAIL PROTECTED] 2007-12-15 14:19 --- > > Krzysztof, I'd hate point you to a hard path (at least time consuming), but > > you've done a lot of digging by now anyway. How about git bisecting between > > 2.6.20-rc2 and rc1? Here is great info on bisecting: > > http://www.kernel.org/doc/local/git-quick.html > > As I'm smarter than git-bistect I can tell that 2.6.20-rc1-git8 is as bad > as 2.6.20-rc2 but 2.6.20-rc1-git8 with one patch reverted seems to be OK. > So it took me only 2 reboots. ;) > > The guilty patch is the one I proposed just an hour ago: > > http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.20.y.git;a=commitdiff_plain;h=fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 > > So: > - 2.6.20-rc1: OK > - 2.6.20-rc1-git8 with fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 reverted: OK > - 2.6.20-rc1-git8: very BAD > - 2.6.20-rc2: very BAD > - 2.6.20-rc4: very BAD > - >= 2.6.20: BAD (but not *very* BAD!) > well.. We have code which has been used by *everyone* for a year and it's misbehaving for you alone. I wonder what you're doing that is different/special. Which filesystem, which mount options, what sort of workload? 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: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
On Sat, 15 Dec 2007 15:55:09 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 15, 2007 3:13 PM, Miles Lane <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 15, 2007 6:13 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > > On Fri, 14 Dec 2007 17:13:21 -0500
> > > > > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > > > Sorry Andrew, I don't know who to forward this problem to.
> > > > > >
> > > > > > I tried running: find /proc | xargs cat
> > > > > > and got this:
> > > > > >
> > > > > > =
> > > > > > [ INFO: inconsistent lock state ]
> > > > > > 2.6.24-rc5-mm1 #26
> > > > > > -
> > > > > > inconsistent {in-softirq-W} -> {softirq-on-R} usage.
> > > > > > cat/6944 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > > > > > BUG: unable to handle kernel paging request at virtual address
> > > > > > 0f1eff0b
> > > > > > printing ip: c01fe64d *pde =
> > > > > > Oops: [#1] PREEMPT SMP
> > > > > > last sysfs file: /sys/block/sda/sda3/stat
> > > > > > Modules linked in: aes_generic i915 drm rfcomm l2cap bluetooth
> > > > > > cpufreq_stats cpufreq_conservative cpufreq_performance sbs sbshc
> > > > > > dm_crypt sbp2 parport_pc lp parport pcmcia arc4 ecb crypto_blkcipher
> > > > > > cryptomgr crypto_algapi tifm_7xx1 tifm_core yenta_socket
> > > > > > rsrc_nonstatic pcmcia_core iwl3945 iTCO_wdt iTCO_vendor_support
> > > > > > watchdog_core watchdog_dev snd_hda_intel mac80211 snd_pcm_oss
> > > > > > snd_mixer_oss cfg80211 snd_pcm sky2 snd_seq_dummy snd_seq_oss
> > > > > > snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> > > > > > snd_seq_device snd soundcore snd_page_alloc shpchp pci_hotplug
> > > > > > firewire_ohci firewire_core crc_itu_t ata_generic piix ide_core
> > > > > >
> > > > > > Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26)
> > > > > > EIP: 0060:[] EFLAGS: 00210097 CPU: 0
> > > > > > EIP is at strnlen+0x9/0x1c
> > > > > > EAX: 0f1eff0b EBX: 0f1eff0b ECX: 0f1eff0b EDX: fffe
> > > > > > ESI: c05b74f6 EDI: d6267d94 EBP: d6267cc8 ESP: d6267cc8
> > > > > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > > > > > Process cat (pid: 6944, ti=d6267000 task=d5a09000 task.ti=d6267000)
> > > > > > Stack: d6267cfc c01fdd22 0400 c05b74f4 0001 c05b78f4
> > > > > >
> > > > > > c048f503 0400 d5a09000 0002 d6267d0c
> > > > > > c01fdf41 d6267d94
> > > > > >db68c04a d6267d74 c012ae81 d6267d94 0028 c05b89f7
> > > > > > 00200046
> > > > > > Call Trace:
> > > > > > [] show_trace_log_lvl+0x12/0x25
> > > > > > [] show_stack_log_lvl+0x8a/0x95
> > > > > > [] show_registers+0x8a/0x1bd
> > > > > > [] die+0x118/0x1dc
> > > > > > [] do_page_fault+0x5a4/0x681
> > > > > > [] error_code+0x72/0x78
> > > > > > [] vsnprintf+0x277/0x40e
> > > > > > [] vscnprintf+0xe/0x1d
> > > > > > [] vprintk+0xcb/0x2f3
> > > > > > [] printk+0x15/0x17
> > > > > > [] print_lock_name+0x4e/0xa2
> > > > > > [] print_lock+0xe/0x3a
> > > > > > [] print_usage_bug+0xbc/0x117
> > > > > > [] mark_lock+0x2e7/0x3fe
> > > > > > [] __lock_acquire+0x498/0xbf4
> > > > > > [] lock_acquire+0x76/0x9d
> > > > > > [] _read_lock+0x23/0x32
> > > > > > [] sock_i_ino+0x14/0x30
> > > > > > [] packet_seq_show+0x22/0x75
> > > > > > [] seq_read+0x19d/0x26f
> > > > > > [] proc_reg_read+0x60/0x74
> > > > > > [] vfs_read+0x8a/0x106
> > > > > > [] sys_read+0x3b/0x60
> > > > > > [] sysenter_past_esp+0x6b/0xc1
> > > > > > ===
> > > > > > Code: 01 00 00 00 4f 89 fa 5f 89 d0 5d c3 55 85 c9 89 e5 57 89 c7 89
> > > > > > d0 74 05 f2 ae 75 01 4f 89 f8 5f 5d c3 55 89 c1 89 e5 89 c8 eb 06
> > > > > > <80>
> > > > > > 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 83
> > > > > > EIP: [] strnlen+0x9/0x1c SS:ESP 0068:d6267cc8
> > > > > > note: cat[6944] exited with preempt_count 4
> > > > >
> > > > > I'd say you hit a networking locking bug and then when trying to
> > > > > report
> > > > > that bug, lockdep crashed.
> > > > >
> > > > > The networking bug looks to be around sock_i_ino()'s taking of
> > > > > sk_callback_lock with softirq's enabled. Perhaps this will fix it.
> > > > >
> > > > > diff -puN net/core/sock.c~a net/core/sock.c
> > > > > --- a/net/core/sock.c~a
> > > > > +++ a/net/core/sock.c
> > > > > @@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
> > > > > {
> > > > > int uid;
> > > > >
> > > > > - read_lock(>sk_callback_lock);
> > > > > + read_lock_bh(>sk_callback_lock);
> > > > > uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
> > > > > - read_unlock(>sk_callback_lock);
> > > > > + read_unlock_bh(>sk_callback_lock);
> > > > > return uid;
> > > > > }
> > > > >
> > > > > @@ -1125,9 +1125,9 @@ unsigned long
Re: [PATCH 0/3] Add GD-Rom support to the SEGA Dreamcast
On Sun, Dec 16, 2007 at 12:20:54AM +, Adrian McMenamin wrote: > This device is electrically compatible with ATA-3 IDE CD drives but > implements a proprietary packet interface. There have been previous > Dreamcast CD drivers around but this is new code and uses DMA as > opposed to PIO for reads. > > It also supports reading the proprietary GD Rom format disks. > > The driver will live as drivers/sh/gdrom/gdrom.c > No, the driver will live in drivers/cdrom if that's the API that you depend on. The only things in drivers/sh are SH-specific bus support code, it is not a dumping ground for unrelated drivers. -- 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/
[PACKET]: Fix /proc/net/packet crash due to bogus private pointer
On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
>
> I suspect namespace borkage. But just because you pin-pointed
> my patch I'll try to track it down :)
Surprise surprise. The namespace seq patch missed two spots in
AF_PACKET.
[PACKET]: Fix /proc/net/packet crash due to bogus private pointer
The seq_open_net patch changed the meaning of seq->private.
Unfortunately it missed two spots in AF_PACKET, which still
used the old way of dereferencing seq->private, thus causing
weird and wonderful crashes when reading /proc/net/packet.
This patch fixes them.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 485af56..43e49f4 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1878,7 +1878,7 @@ static void *packet_seq_start(struct seq_file *seq,
loff_t *pos)
static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
- struct net *net = seq->private;
+ struct net *net = seq_file_net(seq);
++*pos;
return (v == SEQ_START_TOKEN)
? sk_head(>packet.sklist)
@@ -1887,7 +1887,7 @@ static void *packet_seq_next(struct seq_file *seq, void
*v, loff_t *pos)
static void packet_seq_stop(struct seq_file *seq, void *v)
{
- struct net *net = seq->private;
+ struct net *net = seq_file_net(seq);
read_unlock(>packet.sklist_lock);
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sonntag, 16. Dezember 2007, Rafael J. Wysocki wrote: > On Saturday, 15 of December 2007, John W. Linville wrote: > > On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > > > On Friday, 14 of December 2007, Michael Buesch wrote: > > > > > > Either distributions have to install it automatically or people simply > > > > have > > > > to read one or two lines of documentation. That's just what I wanted > > > > to say. > > > > > > It's not that simple. For example, regression testing will be a major > > > PITA > > > if one needs to switch back and forth from the new driver to the old one > > > in the > > > process. > > > > Not really true -- a single system can easily have firmware installed > > for b43, b43legacy, and bcm43xx at the same time and switch back and > > forth between them. > > > > Given a functioning udev configuration, the persistent naming even > > works so that your device stays as 'eth1' when switching to and > > fro bcm43xx. > > Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-) The persistent interface naming rules of udev, at least up to 0.114-2 (current debian unstable), seem to be easily confused if the driver names change for the same MAC address. This issue seems not to be b43 specific, it happens with zd1211rw --> zd1211rw_mac80211 (this one won't show up in mainline kernels), prism54 --> p54pci/ p54usb, out-of-tree RaLink legacy/ serialmonkey (which ignore interface renames through udev completely) --> rt2x00 just as well and I assume that it might also affect sk98lin --> skge/ sky and the upcomming e1000 --> e1000e transitions and similar situations. > > I really think everyone is overstating the problem. > > You might be right. It is of course confusing to the user and might affect remote updates, but it's also easily fixed by removing the generated MAC address mappings and letting udev generate new ones (+ post processing, if needed) during the next boot. > Greetings, > Rafael Regards Stefan Lippers-Hollmann -- 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.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> My suspicion is that you've hit bad breakage in networking and lockdep just
> isn't sufficiently robust to handle what it's being given.
>
> Can you suggest a way in which others can reproduce this?
I can reproduce this now. I suspect it's to do with the namespace
work. I'll let you know when I have digged further.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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.24-rc5-mm1: cat /proc/net/packet -> oops
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
>
> git-ubi.patch
> GOOD
> #
> git-net.patch
> BAD
> ipsec-fix-reversed-icmp6-policy-check.patch
>
> but this seems to be far from precise :)
I suspect namespace borkage. But just because you pin-pointed
my patch I'll try to track it down :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 3/3] [UDP6]: Counter increment on BH mode
On Sat, Dec 15, 2007 at 07:43:28PM +0100, Ingo Molnar wrote:
>
> we could perhaps introduce stat_smp_processor_id(), which signals that
> the CPU id is used for statistical purposes and does not have to be
> exact? In any case, your patch looks good too.
Unfortunately that doesn't work because we can then have two
CPUs trying to update the same counter which may corrupt it.
However, an optimisation is indeed possible with some work.
If we can get the address of the per-cpu counter against
some sort of a per-cpu base pointer, e.g., %gs on x86, then
we can do
incq%gs:(%rax)
where %rax would be the offset with %gs as the base. This would
obviate the need for the CPU ID and therefore avoid disabling
preemption.
Hmm, wasn't Christoph working on something like that?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some "newer" cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power control problem was "solved" in b43, there is very little difference. When I built my special system to use the BCM4311 with b43legacy, there was no difference. I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing SoftMAC with mac80211. There is, of course, no comparison. Larry -- 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/
[SNMP]: Fix SNMP counters with PREEMPT
On Sat, Dec 15, 2007 at 06:03:19PM +0100, Eric Dumazet wrote:
>
> How come you change SNMP_INC_STATS_USER() but not SNMP_INC_STATS() ?
Heh, my brain must have blocked me from seeing it because it's
too hard :)
Let's fix it the stupid way first and I'll do a local_t conversion
later.
[SNMP]: Fix SNMP counters with PREEMPT
The SNMP macros use raw_smp_processor_id() in process context
which is illegal because the process may be preempted and then
migrated to another CPU.
This patch makes it use get_cpu/put_cpu to disable preemption.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/net/snmp.h b/include/net/snmp.h
index 9c5793d..fbb 100644
--- a/include/net/snmp.h
+++ b/include/net/snmp.h
@@ -23,6 +23,7 @@
#include
#include
+#include
/*
* Mibs are stored in array of unsigned long.
@@ -135,14 +136,26 @@ struct linux_mib {
#define SNMP_INC_STATS_BH(mib, field) \
(per_cpu_ptr(mib[0], raw_smp_processor_id())->mibs[field]++)
#define SNMP_INC_STATS_USER(mib, field) \
- (per_cpu_ptr(mib[1], raw_smp_processor_id())->mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())->mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_INC_STATS(mib, field) \
- (per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())->mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[!in_softirq()], get_cpu())->mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_DEC_STATS(mib, field) \
- (per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())->mibs[field]--)
+ do { \
+ per_cpu_ptr(mib[!in_softirq()], get_cpu())->mibs[field]--; \
+ put_cpu(); \
+ } while (0)
#define SNMP_ADD_STATS_BH(mib, field, addend) \
(per_cpu_ptr(mib[0], raw_smp_processor_id())->mibs[field] += addend)
#define SNMP_ADD_STATS_USER(mib, field, addend)\
- (per_cpu_ptr(mib[1], raw_smp_processor_id())->mibs[field] += addend)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())->mibs[field] += addend; \
+ put_cpu(); \
+ } while (0)
#endif
--
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 RESEND] asm-*/compat.h: fix typo in comment
comverted -> converted
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
include/asm-ia64/compat.h|2 +-
include/asm-mips/compat.h|2 +-
include/asm-parisc/compat.h |2 +-
include/asm-powerpc/compat.h |2 +-
include/asm-s390/compat.h|2 +-
include/asm-sparc64/compat.h |2 +-
include/asm-x86/compat.h |2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/asm-ia64/compat.h b/include/asm-ia64/compat.h
index 0f6e526..dfcf75b 100644
--- a/include/asm-ia64/compat.h
+++ b/include/asm-ia64/compat.h
@@ -181,7 +181,7 @@ struct compat_shmid64_ds {
/*
* A pointer passed in from user mode. This should not be used for syscall
parameters,
* just declare them as pointers because the syscall entry code will have
appropriately
- * comverted them already.
+ * converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-mips/compat.h b/include/asm-mips/compat.h
index 568c76c..ac5d541 100644
--- a/include/asm-mips/compat.h
+++ b/include/asm-mips/compat.h
@@ -128,7 +128,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedef u32compat_uptr_t;
diff --git a/include/asm-parisc/compat.h b/include/asm-parisc/compat.h
index 5a85d1b..7f32611 100644
--- a/include/asm-parisc/compat.h
+++ b/include/asm-parisc/compat.h
@@ -132,7 +132,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-powerpc/compat.h b/include/asm-powerpc/compat.h
index 64ab1dd..d811a8c 100644
--- a/include/asm-powerpc/compat.h
+++ b/include/asm-powerpc/compat.h
@@ -119,7 +119,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-s390/compat.h b/include/asm-s390/compat.h
index 7f4ad62..de065b3 100644
--- a/include/asm-s390/compat.h
+++ b/include/asm-s390/compat.h
@@ -149,7 +149,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-sparc64/compat.h b/include/asm-sparc64/compat.h
index 01fe668..f260b58 100644
--- a/include/asm-sparc64/compat.h
+++ b/include/asm-sparc64/compat.h
@@ -152,7 +152,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-x86/compat.h b/include/asm-x86/compat.h
index 66ba798..0e18cb5 100644
--- a/include/asm-x86/compat.h
+++ b/include/asm-x86/compat.h
@@ -190,7 +190,7 @@ typedef struct user_regs_struct32 compat_elf_gregset_t;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
--
1.5.3.4
--
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 RESEND] ehci-hcd: fix sparse warning about shadowing 'status' symbol
fix warning:
drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an earlier
one
drivers/usb/host/ehci-hcd.c:790:71: originally declared here
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-hcd.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 5f2d74e..e531f51 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -829,16 +829,16 @@ static int ehci_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
/* reschedule QH iff another request is queued */
if (!list_empty (>qtd_list)
&& HC_IS_RUNNING (hcd->state)) {
- int status;
+ int schedule_status;
- status = qh_schedule (ehci, qh);
+ schedule_status = qh_schedule (ehci, qh);
spin_unlock_irqrestore (>lock, flags);
- if (status != 0) {
+ if (schedule_status != 0) {
// shouldn't happen often, but ...
// FIXME kill those tds' urbs
err ("can't reschedule qh %p, err %d",
- qh, status);
+ qh, schedule_status);
}
return status;
}
--
1.5.3.4
--
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 RESEND] usbdevfs_urb: __user annotation
fix warning:
drivers/usb/core/devio.c:1226:20: warning: incorrect type in assignment
(different address spaces)
drivers/usb/core/devio.c:1226:20:expected void *usercontext
drivers/usb/core/devio.c:1226:20:got void [noderef] *
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/linux/usbdevice_fs.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/usbdevice_fs.h b/include/linux/usbdevice_fs.h
index 8ca5a7f..17cb108 100644
--- a/include/linux/usbdevice_fs.h
+++ b/include/linux/usbdevice_fs.h
@@ -104,7 +104,7 @@ struct usbdevfs_urb {
int error_count;
unsigned int signr; /* signal to be sent on completion,
or 0 if none should be sent. */
- void *usercontext;
+ void __user *usercontext;
struct usbdevfs_iso_packet_desc iso_frame_desc[0];
};
--
1.5.3.4
--
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 RESEND] usb/storage/initializers.c: fix signedness difference
fix warnings:
drivers/usb/storage/initializers.c:83:26: warning: incorrect type in argument 5
(different signedness)
drivers/usb/storage/initializers.c:83:26:expected unsigned int *act_len
drivers/usb/storage/initializers.c:83:26:got int *
drivers/usb/storage/initializers.c:89:26: warning: incorrect type in argument 5
(different signedness)
drivers/usb/storage/initializers.c:89:26:expected unsigned int *act_len
drivers/usb/storage/initializers.c:89:26:got int *
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/storage/initializers.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/storage/initializers.c
b/drivers/usb/storage/initializers.c
index ee5b42a..187dd1e 100644
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -66,7 +66,8 @@ int usb_stor_ucr61s2b_init(struct us_data *us)
{
struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap*) us->iobuf;
struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap*) us->iobuf;
- int res, partial;
+ int res;
+ unsigned int partial;
static char init_string[] = "\xec\x0a\x06\x00$PCCHIPS";
US_DEBUGP("Sending UCR-61S2B initialization packet...\n");
--
1.5.3.4
--
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 6/6] udf: fix sparse warnings (shadowing & mismatch between declaration and definition)
fix warnings:
fs/udf/super.c:1320:24: warning: symbol 'bh' shadows an earlier one
fs/udf/super.c:1240:21: originally declared here
fs/udf/super.c:1583:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1418:6: originally declared here
fs/udf/super.c:1585:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1418:6: originally declared here
fs/udf/super.c:1658:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1648:6: originally declared here
fs/udf/super.c:1660:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1648:6: originally declared here
fs/udf/super.c:450:6: warning: symbol 'udf_write_super' was not declared.
Should it be static?
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
---
fs/udf/super.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4360c7a..9f82b5a 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -447,7 +447,7 @@ static int udf_parse_options(char *options, struct
udf_options *uopt)
return 1;
}
-void udf_write_super(struct super_block *sb)
+static void udf_write_super(struct super_block *sb)
{
lock_kernel();
@@ -1317,7 +1317,6 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
UDF_SB_TYPEVIRT(sb, i).s_num_entries =
(UDF_SB_VAT(sb)->i_size - 36) >> 2;
} else if (UDF_SB_PARTTYPE(sb, i) == UDF_VIRTUAL_MAP20)
{
- struct buffer_head *bh = NULL;
uint32_t pos;
pos = udf_block_map(UDF_SB_VAT(sb), 0);
@@ -1415,7 +1414,7 @@ static void udf_close_lvid(struct super_block *sb)
*/
static int udf_fill_super(struct super_block *sb, void *options, int silent)
{
- int i;
+ int idx;
struct inode *inode = NULL;
struct udf_options uopt;
kernel_lb_addr rootdir, fileset;
@@ -1584,8 +1583,8 @@ error_out:
if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_FREED_BITMAP)
UDF_SB_FREE_BITMAP(sb,UDF_SB_PARTITION(sb), s_fspace);
if (UDF_SB_PARTTYPE(sb, UDF_SB_PARTITION(sb)) ==
UDF_SPARABLE_MAP15) {
- for (i = 0; i < 4; i++)
- brelse(UDF_SB_TYPESPAR(sb,
UDF_SB_PARTITION(sb)).s_spar_map[i]);
+ for (idx = 0; idx < 4; idx++)
+ brelse(UDF_SB_TYPESPAR(sb,
UDF_SB_PARTITION(sb)).s_spar_map[idx]);
}
}
#ifdef CONFIG_UDF_NLS
@@ -1645,7 +1644,7 @@ void udf_warning(struct super_block *sb, const char
*function,
*/
static void udf_put_super(struct super_block *sb)
{
- int i;
+ int idx;
if (UDF_SB_VAT(sb))
iput(UDF_SB_VAT(sb));
@@ -1659,8 +1658,8 @@ static void udf_put_super(struct super_block *sb)
if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_FREED_BITMAP)
UDF_SB_FREE_BITMAP(sb,UDF_SB_PARTITION(sb), s_fspace);
if (UDF_SB_PARTTYPE(sb, UDF_SB_PARTITION(sb)) ==
UDF_SPARABLE_MAP15) {
- for (i = 0; i < 4; i++)
- brelse(UDF_SB_TYPESPAR(sb,
UDF_SB_PARTITION(sb)).s_spar_map[i]);
+ for (idx = 0; idx < 4; idx++)
+ brelse(UDF_SB_TYPESPAR(sb,
UDF_SB_PARTITION(sb)).s_spar_map[idx]);
}
}
#ifdef CONFIG_UDF_NLS
--
1.5.3.4
--
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 5/6] udf: fix signedness issue
sparse generated:
fs/udf/namei.c:896:15: originally declared here
fs/udf/namei.c:1147:41: warning: incorrect type in argument 3 (different
signedness)
fs/udf/namei.c:1147:41:expected int *offset
fs/udf/namei.c:1147:41:got unsigned int *
fs/udf/namei.c:1152:78: warning: incorrect type in argument 3 (different
signedness)
fs/udf/namei.c:1152:78:expected int *offset
fs/udf/namei.c:1152:78:got unsigned int *
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/namei.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index bec96a6..066153f 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -1131,7 +1131,7 @@ static int udf_rename(struct inode *old_dir, struct
dentry *old_dentry,
}
}
if (S_ISDIR(old_inode->i_mode)) {
- uint32_t offset = udf_ext0_offset(old_inode);
+ int offset = udf_ext0_offset(old_inode);
if (new_inode) {
retval = -ENOTEMPTY;
--
1.5.3.4
--
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/6] udf: fix 3 signedness & 1 unitialized variable warnings
sparse generated:
fs/udf/inode.c:324:41: warning: incorrect type in argument 4 (different
signedness)
fs/udf/inode.c:324:41:expected long *
fs/udf/inode.c:324:41:got unsigned long *
inode_getblk always set 4th argument to uint32_t value
3rd parameter of map_bh is sector_t (which is unsigned long or u64)
so convert phys value to sector_t
fs/udf/inode.c:1818:47: warning: incorrect type in argument 3 (different
signedness)
fs/udf/inode.c:1818:47:expected int *
fs/udf/inode.c:1818:47:got unsigned int *
fs/udf/inode.c:1826:46: warning: incorrect type in argument 3 (different
signedness)
fs/udf/inode.c:1826:46:expected int *
fs/udf/inode.c:1826:46:got unsigned int *
udf_get_filelongad and udf_get_shortad are called always for uint32_t
values (struct extent_position->offset), so it's safe to convert offset
parameter to uint32_t
gcc warned:
fs/udf/inode.c: In function 'udf_get_block':
fs/udf/inode.c:299: warning: 'phys' may be used uninitialized in this function
initialize it to 0 (if someday someone will break inode_getblk we will catch it
immediately)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
---
fs/udf/directory.c |8
fs/udf/inode.c |6 +++---
fs/udf/udfdecl.h |4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/udf/directory.c b/fs/udf/directory.c
index ff8c08f..984e5dc 100644
--- a/fs/udf/directory.c
+++ b/fs/udf/directory.c
@@ -271,7 +271,7 @@ static extent_ad *udf_get_fileextent(void *buffer, int
bufsize, int *offset)
}
#endif
-short_ad *udf_get_fileshortad(uint8_t *ptr, int maxoffset, int *offset,
+short_ad *udf_get_fileshortad(uint8_t *ptr, int maxoffset, uint32_t *offset,
int inc)
{
short_ad *sa;
@@ -281,7 +281,7 @@ short_ad *udf_get_fileshortad(uint8_t *ptr, int maxoffset,
int *offset,
return NULL;
}
- if ((*offset < 0) || ((*offset + sizeof(short_ad)) > maxoffset))
+ if ((*offset + sizeof(short_ad)) > maxoffset)
return NULL;
else if ((sa = (short_ad *)ptr)->extLength == 0)
return NULL;
@@ -291,7 +291,7 @@ short_ad *udf_get_fileshortad(uint8_t *ptr, int maxoffset,
int *offset,
return sa;
}
-long_ad *udf_get_filelongad(uint8_t *ptr, int maxoffset, int *offset, int inc)
+long_ad *udf_get_filelongad(uint8_t *ptr, int maxoffset, uint32_t *offset, int
inc)
{
long_ad *la;
@@ -300,7 +300,7 @@ long_ad *udf_get_filelongad(uint8_t *ptr, int maxoffset,
int *offset, int inc)
return NULL;
}
- if ((*offset < 0) || ((*offset + sizeof(long_ad)) > maxoffset))
+ if ((*offset + sizeof(long_ad)) > maxoffset)
return NULL;
else if ((la = (long_ad *)ptr)->extLength == 0)
return NULL;
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 6ff8151..1178ae0 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -51,7 +51,7 @@ static int udf_update_inode(struct inode *, int);
static void udf_fill_inode(struct inode *, struct buffer_head *);
static int udf_alloc_i_data(struct inode *inode, size_t size);
static struct buffer_head *inode_getblk(struct inode *, sector_t, int *,
- long *, int *);
+ sector_t *, int *);
static int8_t udf_insert_aext(struct inode *, struct extent_position,
kernel_lb_addr, uint32_t);
static void udf_split_extents(struct inode *, int *, int, int,
@@ -296,7 +296,7 @@ static int udf_get_block(struct inode *inode, sector_t
block,
{
int err, new;
struct buffer_head *bh;
- unsigned long phys;
+ sector_t phys = 0;
if (!create) {
phys = udf_block_map(inode, block);
@@ -469,7 +469,7 @@ out:
}
static struct buffer_head *inode_getblk(struct inode *inode, sector_t block,
- int *err, long *phys, int *new)
+ int *err, sector_t *phys, int *new)
{
static sector_t last_block;
struct buffer_head *result = NULL;
diff --git a/fs/udf/udfdecl.h b/fs/udf/udfdecl.h
index c8016cc..b17ca67 100644
--- a/fs/udf/udfdecl.h
+++ b/fs/udf/udfdecl.h
@@ -185,8 +185,8 @@ extern struct fileIdentDesc *udf_fileident_read(struct
inode *, loff_t *,
sector_t *);
extern struct fileIdentDesc *udf_get_fileident(void *buffer, int bufsize,
int *offset);
-extern long_ad *udf_get_filelongad(uint8_t *, int, int *, int);
-extern short_ad *udf_get_fileshortad(uint8_t *, int, int *, int);
+extern long_ad *udf_get_filelongad(uint8_t *, int, uint32_t *, int);
+extern short_ad *udf_get_fileshortad(uint8_t *, int, uint32_t *, int);
/* crc.c */
extern uint16_t udf_crc(uint8_t *, uint32_t, uint16_t);
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe
[PATCH 3/6] udf: fix coding style of dir.c
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
---
fs/udf/dir.c | 46 +++---
1 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/fs/udf/dir.c b/fs/udf/dir.c
index c26e281..c5e38d6 100644
--- a/fs/udf/dir.c
+++ b/fs/udf/dir.c
@@ -65,24 +65,26 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
if (nf_pos == 0)
nf_pos = (udf_ext0_offset(dir) >> 2);
- fibh.soffset = fibh.eoffset = (nf_pos & ((dir->i_sb->s_blocksize - 1)
>> 2)) << 2;
+ fibh.soffset = fibh.eoffset =
+ (nf_pos & ((dir->i_sb->s_blocksize - 1) >> 2)) << 2;
bits = dir->i_sb->s_blocksize_bits;
- if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_IN_ICB) {
+ if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_IN_ICB)
fibh.sbh = fibh.ebh = NULL;
- } else if (inode_bmap(dir, nf_pos >> (bits - 2),
- , , , ) ==
(EXT_RECORDED_ALLOCATED >> 30)) {
+ else if (inode_bmap(dir, nf_pos >> (bits - 2),
+ , , , ) ==
+ (EXT_RECORDED_ALLOCATED >> 30)) {
block = udf_get_lb_pblock(dir->i_sb, eloc, offset);
if ((++offset << bits) < elen) {
if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_SHORT)
epos.offset -= sizeof(short_ad);
else if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_LONG)
epos.offset -= sizeof(long_ad);
- } else {
+ } else
offset = 0;
- }
- if (!(fibh.sbh = fibh.ebh = udf_tread(dir->i_sb, block))) {
+ fibh.sbh = fibh.ebh = udf_tread(dir->i_sb, block);
+ if (!fibh.sbh) {
brelse(epos.bh);
return -EIO;
}
@@ -92,9 +94,11 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
if (i + offset > (elen >> bits))
i = (elen >> bits) - offset;
for (num = 0; i > 0; i--) {
- block = udf_get_lb_pblock(dir->i_sb, eloc,
offset + i);
+ block = udf_get_lb_pblock(dir->i_sb, eloc,
+ offset + i);
tmp = udf_tgetblk(dir->i_sb, block);
- if (tmp && !buffer_uptodate(tmp) &&
!buffer_locked(tmp))
+ if (tmp && !buffer_uptodate(tmp) &&
+ !buffer_locked(tmp))
bha[num++] = tmp;
else
brelse(tmp);
@@ -126,16 +130,18 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
liu = le16_to_cpu(cfi.lengthOfImpUse);
lfi = cfi.lengthFileIdent;
- if (fibh.sbh == fibh.ebh) {
+ if (fibh.sbh == fibh.ebh)
nameptr = fi->fileIdent + liu;
- } else {
+ else {
int poffset;/* Unpaded ending offset */
- poffset = fibh.soffset + sizeof(struct fileIdentDesc) +
liu + lfi;
+ poffset = fibh.soffset + sizeof(struct fileIdentDesc) +
+ liu + lfi;
- if (poffset >= lfi) {
- nameptr = (char *)(fibh.ebh->b_data + poffset -
lfi);
- } else {
+ if (poffset >= lfi)
+ nameptr = (char *)(fibh.ebh->b_data +
+ poffset - lfi);
+ else {
nameptr = fname;
memcpy(nameptr, fi->fileIdent + liu,
lfi - poffset);
@@ -168,12 +174,13 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
}
if (flen) {
- if (filldir(dirent, fname, flen, filp->f_pos, iblock,
dt_type) < 0) {
+ if (filldir(dirent, fname, flen, filp->f_pos, iblock,
+ dt_type) < 0) {
if (fibh.sbh != fibh.ebh)
brelse(fibh.ebh);
brelse(fibh.sbh);
brelse(epos.bh);
- return 0;
+ return 0;
}
}
} /* end while */
@@ -222,7 +229,8 @@ static int udf_readdir(struct file *filp, void *dirent,
filldir_t filldir)
lock_kernel();
if (filp->f_pos == 0) {
- if (filldir(dirent, ".", 1, filp->f_pos,
[PATCH 2/6] udf: improve readability of do_udf_readdir
make reading do_udf_readdir easier by adding new variable
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
---
fs/udf/dir.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/udf/dir.c b/fs/udf/dir.c
index 174d2fc..c26e281 100644
--- a/fs/udf/dir.c
+++ b/fs/udf/dir.c
@@ -57,6 +57,7 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
int i, num;
unsigned int dt_type;
struct extent_position epos = { NULL, 0, {0, 0} };
+ unsigned char bits;
if (nf_pos >= size)
return 0;
@@ -65,12 +66,14 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
nf_pos = (udf_ext0_offset(dir) >> 2);
fibh.soffset = fibh.eoffset = (nf_pos & ((dir->i_sb->s_blocksize - 1)
>> 2)) << 2;
+ bits = dir->i_sb->s_blocksize_bits;
+
if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_IN_ICB) {
fibh.sbh = fibh.ebh = NULL;
- } else if (inode_bmap(dir, nf_pos >> (dir->i_sb->s_blocksize_bits - 2),
+ } else if (inode_bmap(dir, nf_pos >> (bits - 2),
, , , ) ==
(EXT_RECORDED_ALLOCATED >> 30)) {
block = udf_get_lb_pblock(dir->i_sb, eloc, offset);
- if ((++offset << dir->i_sb->s_blocksize_bits) < elen) {
+ if ((++offset << bits) < elen) {
if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_SHORT)
epos.offset -= sizeof(short_ad);
else if (UDF_I_ALLOCTYPE(dir) == ICBTAG_FLAG_AD_LONG)
@@ -84,10 +87,10 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
return -EIO;
}
- if (!(offset & ((16 >> (dir->i_sb->s_blocksize_bits - 9)) -
1))) {
- i = 16 >> (dir->i_sb->s_blocksize_bits - 9);
- if (i + offset > (elen >> dir->i_sb->s_blocksize_bits))
- i = (elen >> dir->i_sb->s_blocksize_bits) -
offset;
+ if (!(offset & ((16 >> (bits - 9)) - 1))) {
+ i = 16 >> (bits - 9);
+ if (i + offset > (elen >> bits))
+ i = (elen >> bits) - offset;
for (num = 0; i > 0; i--) {
block = udf_get_lb_pblock(dir->i_sb, eloc,
offset + i);
tmp = udf_tgetblk(dir->i_sb, block);
--
1.5.3.4
--
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/6] udf: remove wrong prototype of udf_readdir
sparse generated:
fs/udf/dir.c:78:5: warning: symbol 'udf_readdir' was not declared. Should it be
static?
there are 2 different prototypes of udf_readdir - remove them and move
code around to make it still compile
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
---
fs/udf/dir.c | 118 +++--
1 files changed, 56 insertions(+), 62 deletions(-)
diff --git a/fs/udf/dir.c b/fs/udf/dir.c
index 9e3b9f9..174d2fc 100644
--- a/fs/udf/dir.c
+++ b/fs/udf/dir.c
@@ -36,68 +36,8 @@
#include "udf_i.h"
#include "udf_sb.h"
-/* Prototypes for file operations */
-static int udf_readdir(struct file *, void *, filldir_t);
-static int do_udf_readdir(struct inode *, struct file *, filldir_t, void *);
-
-/* readdir and lookup functions */
-
-const struct file_operations udf_dir_operations = {
- .read = generic_read_dir,
- .readdir= udf_readdir,
- .ioctl = udf_ioctl,
- .fsync = udf_fsync_file,
-};
-
-/*
- * udf_readdir
- *
- * PURPOSE
- * Read a directory entry.
- *
- * DESCRIPTION
- * Optional - sys_getdents() will return -ENOTDIR if this routine is not
- * available.
- *
- * Refer to sys_getdents() in fs/readdir.c
- * sys_getdents() -> .
- *
- * PRE-CONDITIONS
- * filpPointer to directory file.
- * buf Pointer to directory entry buffer.
- * filldir Pointer to filldir function.
- *
- * POST-CONDITIONS
- * >=0 on success.
- *
- * HISTORY
- * July 1, 1997 - Andrew E. Mileski
- * Written, tested, and released.
- */
-
-int udf_readdir(struct file *filp, void *dirent, filldir_t filldir)
-{
- struct inode *dir = filp->f_path.dentry->d_inode;
- int result;
-
- lock_kernel();
-
- if (filp->f_pos == 0) {
- if (filldir(dirent, ".", 1, filp->f_pos, dir->i_ino, DT_DIR) <
0) {
- unlock_kernel();
- return 0;
- }
- filp->f_pos++;
- }
-
- result = do_udf_readdir(dir, filp, filldir, dirent);
- unlock_kernel();
- return result;
-}
-
-static int
-do_udf_readdir(struct inode *dir, struct file *filp, filldir_t filldir,
- void *dirent)
+static int do_udf_readdir(struct inode *dir, struct file *filp,
+ filldir_t filldir, void *dirent)
{
struct udf_fileident_bh fibh;
struct fileIdentDesc *fi = NULL;
@@ -244,3 +184,57 @@ do_udf_readdir(struct inode *dir, struct file *filp,
filldir_t filldir,
return 0;
}
+
+/*
+ * udf_readdir
+ *
+ * PURPOSE
+ * Read a directory entry.
+ *
+ * DESCRIPTION
+ * Optional - sys_getdents() will return -ENOTDIR if this routine is not
+ * available.
+ *
+ * Refer to sys_getdents() in fs/readdir.c
+ * sys_getdents() -> .
+ *
+ * PRE-CONDITIONS
+ * filpPointer to directory file.
+ * buf Pointer to directory entry buffer.
+ * filldir Pointer to filldir function.
+ *
+ * POST-CONDITIONS
+ * >=0 on success.
+ *
+ * HISTORY
+ * July 1, 1997 - Andrew E. Mileski
+ * Written, tested, and released.
+ */
+
+static int udf_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+ struct inode *dir = filp->f_path.dentry->d_inode;
+ int result;
+
+ lock_kernel();
+
+ if (filp->f_pos == 0) {
+ if (filldir(dirent, ".", 1, filp->f_pos, dir->i_ino, DT_DIR) <
0) {
+ unlock_kernel();
+ return 0;
+ }
+ filp->f_pos++;
+ }
+
+ result = do_udf_readdir(dir, filp, filldir, dirent);
+ unlock_kernel();
+ return result;
+}
+
+/* readdir and lookup functions */
+const struct file_operations udf_dir_operations = {
+ .read = generic_read_dir,
+ .readdir= udf_readdir,
+ .ioctl = udf_ioctl,
+ .fsync = udf_fsync_file,
+};
--
1.5.3.4
--
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] sound/core.h: include sound/driver.h
On Fri, Dec 14, 2007 at 12:02:46PM +0100, Takashi Iwai wrote: > At Sat, 8 Dec 2007 21:50:45 +0100, > Marcin Ślusarz wrote: > > > > sound/core.h: include sound/driver.h > > > > include sound/driver.h in sound/core.h because core.h > > uses SNDRV_CARDS (which is defined in sound/driver.h) > > > > Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]> > > Right now I have another (bigger) change for this include path, so > this patch won't be needed any more. > > I applied the patches to sound/* except for this one and > sound/memory.c. Thanks! > Is there anything wrong with patch for rawmidi [1]? Marcin [1] http://lkml.org/lkml/2007/12/8/164 -- 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/
Strange Memory Corruption Problem with Core2Duo E6700, P965 Chipset MB and >=4GB RAM
Hi Yesterday i upgraded an 1 year old System from 4x1GB (32Bit, No Memory-Remap) to 4x2GB (64Bit, Memory-Remap) Today i due to a lucky coincidence i discovered that i have a memory corruption problem. This problem happens only with at least 4GB RAM and Memory-Remap. It happens with any 2 of the 4x2GB RAM-Modules and regardless of slot or dual or single channel configuration. After some trying i found a way to "catch" the error. I wrote a small perl script to fill a tmpfs with 1MB zero-files. Then i MD5 all the files and discard all with the MD5-sum of a 1MB zero-file. Here is what hexdump says about the file-content of the "bad"-file when it is called several times. :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff fd0f 00d50b0 * 00d90a0 161f 1fff 43ff 00d90b0 00d90c0 0001 00d90d0 * 010 :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff fd0f 00d50b0 * 00d90a0 e59d 1fff 43bf 00d90b0 00d90c0 0001 00d90d0 * 010 :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff fd0f 00d50b0 * 00d90a0 f7fb 1fff 43ff 00d90b0 00d90c0 0001 00d90d0 * 010 :/misc/badram> hexdump bad 000 * 00d50a0 84cf 1fff ff03 00d50b0 * 00d90a0 df3b 1fff 43ff 00d90b0 00d90c0 0001 00d90d0 * 010 Strange is that some parts are static and other parts change. Kernel is 2.6.23.11. Kernel is 64Bit/x86-64, Userspace is 32bit. I only need the RAM for a huge ramdisk, so i don't need 64bit userspace. Can anybody help me with this problem? Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- 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/
After many hours all outbound connections get stuck in SYN_SENT
Hello, I have a Java application that makes a large number of outbound webservice calls over HTTP/TCP. The hosts contacted are a fixed set of about 2000 hosts and a web service call is made to each of them approximately every 5 mintues by a pool of 200 Java threads. Over time, on average a percentage of these hosts are unreachable for one reason or another, usually because they are on wireless cell phone NICs, so there is a persistent count of sockets in the SYN_SENT state in the range of about 60-80. This is fine, as these failed connection attempts eventually time out. However, after approximately 38 hours of operation, all outbound connection attempts get stuck in the SYN_SENT state. It happens instantaneously, where I go from the baseline of about 60-80 sockets in SYN_SENT to a count of 200 (corresponding to the # of java threads that make these calls). When I stop and start the Java application, all the new outbound connections still get stuck in SYN_SENT state. During this time, I am still able to SSH to the box and run wget to Google, cnn, etc, so the problem appears to be specific to the hosts that I'm accessing via the webservices. For a long time, the only thing that would resolve this was rebooting the entire machine. Once I did this, the outbound connections could be made succesfully. However, very recently when I had once of these incidents I disabled tcp_sack via: echo "0" > /proc/sys/net/ipv4/tcp_sack And the problem almost instanteaously resolved itself and outbound connection attempts were succesful. I hadn't attempted this before because I assumed that if any of my network equipment or remote hosts had a problem with SACK, that it would never work. In my case, it worked fine for about 38 hours before hitting a wall where no outbound connections could be made. I'm running kernel 2.6.18 on RedHat, but have had this problem occur on earlier kernel versions (all 2.4 and 2.6). I know a lot of people will say it must be the firewall, but I've seen had this issue on different router vendors, firewall vendors, different co-location facilities, NICs, and several other variables. I've totaly rebuilt every piece of the archtiecture at one time or another and still see this issue. I've had this problem to varying degrees of severity for the past 4 years or so. Up until this point, the only thing other than a complete machine restart that fixes the problem is disabling tcp_sack. When I disable it, the problem goes away almost instantaneously. Is there a kernel buffer or some data structure that tcp_sack uses that gets filled up after an extended period of operation? How can I debug this problem in the kernel to find out what the root cause is? I've temporarily signed up on this list, but may opt-out if I can't handle the traffic, so please CC me directly on any replies. Thanks, James Nichols -- 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/3] Add GD-Rom support to the SEGA Dreamcast
diff -ruN ./linux-2.6-orig/drivers/sh/gdrom/gdrom.c
./linux-2.6/drivers/sh/gdrom/gdrom.c
--- ./linux-2.6-orig/drivers/sh/gdrom/gdrom.c 1970-01-01
01:00:00.0 +0100
+++ ./linux-2.6/drivers/sh/gdrom/gdrom.c2007-12-15 22:58:17.0
+
@@ -0,0 +1,793 @@
+/* GD ROM driver for the SEGA Dreamcast
+ * copyright Adrian McMenamin, 2007
+ * With thanks to Marcus Comstedt and Nathan Keynes
+ * for work in reversing PIO and DMA
+ *
+ * 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
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GDROM_DEV_NAME "gdrom"
+#define GD_SESSION_OFFSET 150
+
+/* GD Rom commands */
+#define GDROM_COM_SOFTRESET 0x08
+#define GDROM_COM_EXECDIAG 0x90
+#define GDROM_COM_PACKET 0xA0
+#define GDROM_COM_IDDEV 0xA1
+
+/* GD Rom registers */
+#define GDROM_BASE_REG 0xA05F7000
+#define GDROM_ALTSTATUS_REG GDROM_BASE_REG + 0x18
+#define GDROM_DATA_REG GDROM_BASE_REG + 0x80
+#define GDROM_ERROR_REG GDROM_BASE_REG + 0x84
+#define GDROM_INTSEC_REG GDROM_BASE_REG + 0x88
+#define GDROM_SECNUM_REG GDROM_BASE_REG + 0x8C
+#define GDROM_BCL_REG GDROM_BASE_REG + 0x90
+#define GDROM_BCH_REG GDROM_BASE_REG + 0x94
+#define GDROM_DSEL_REG GDROM_BASE_REG + 0x98
+#define GDROM_STATUSCOMMAND_REG GDROM_BASE_REG + 0x9C
+#define GDROM_RESET_REG GDROM_BASE_REG + 0x4E4
+
+#define GDROM_DATA_REG_P0 0x005F7080
+
+#define GDROM_DMA_STARTADDR_REG GDROM_BASE_REG + 0x404
+#define GDROM_DMA_LENGTH_REG GDROM_BASE_REG + 0x408
+#define GDROM_DMA_DIRECTION_REG GDROM_BASE_REG + 0x40C
+#define GDROM_DMA_ENABLE_REG GDROM_BASE_REG + 0x414
+#define GDROM_DMA_STATUS_REG GDROM_BASE_REG + 0x418
+#define GDROM_DMA_WAIT_REG GDROM_BASE_REG + 0x4A0
+#define GDROM_DMA_ACCESS_CTRL_REG GDROM_BASE_REG + 0x4B8
+
+#define GDROMDEBUG 0
+
+#define GDROM_HARD_SECTOR 2048
+#define BLOCK_LAYER_SECTOR 512
+#define GD_TO_BLK 4
+
+static struct platform_device *pd;
+static int gdrom_major;
+static wait_queue_head_t command_queue;
+static wait_queue_head_t request_queue;
+
+static DEFINE_SPINLOCK(gdrom_lock);
+
+struct gdromtoc {
+ unsigned int entry[99];
+ unsigned int first, last;
+ unsigned int leadout;
+};
+
+static struct gdrom_unit {
+ struct gendisk *disk;
+ struct cdrom_device_info *cd_info;
+ int status;
+ int pending;
+ int transfer;
+ char disk_type;
+ struct gdromtoc *toc;
+ struct request_queue *gdrom_rq;
+} gd;
+
+struct gdrom_id {
+ char mid;
+ char modid;
+ char verid;
+ char padA[13];
+ char mname[16];
+ char modname[16];
+ char firmver[16];
+ char padB[16];
+};
+
+static int gdrom_getsense(short *bufstring);
+static int gdrom_packetcommand(struct cdrom_device_info * cd_info,
struct packet_command *command);
+
+static void wait_clrbusy(void)
+{
+ while (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80)
+ schedule();
+}
+
+static void gdrom_wait_busy_sleeps(void)
+{
+ /* Wait to get busy first */
+ while ((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) == 0)
+ schedule();
+ /* Now wait for busy to clear */
+ wait_clrbusy();
+}
+
+static void gdrom_identifydevice(void *buf)
+{
+ int c;
+ short *data = buf;
+ wait_clrbusy();
+ ctrl_outb(GDROM_COM_IDDEV, GDROM_STATUSCOMMAND_REG);
+ gdrom_wait_busy_sleeps();
+ /* now read in the data */
+ for (c = 0; c < 40; c++)
+ data[c] = ctrl_inw(GDROM_DATA_REG);
+}
+
+static void gdrom_spicommand(void *spi_string, int buflen)
+{
+ short *cmd = spi_string;
+ /* ensure IRQ_WAIT is set */
+ ctrl_outb(0x08, GDROM_ALTSTATUS_REG);
+ /* specify how many bytes we expect back */
+ ctrl_outb(buflen & 0xFF, GDROM_BCL_REG);
+ ctrl_outb((buflen >> 8) & 0xFF, GDROM_BCH_REG);
+ /* other parameters */
+ ctrl_outb(0, GDROM_INTSEC_REG);
+ ctrl_outb(0, GDROM_SECNUM_REG);
+ ctrl_outb(0, GDROM_ERROR_REG);
+ /* Wait until we can go */
+ wait_clrbusy();
+ ctrl_outb(GDROM_COM_PACKET, GDROM_STATUSCOMMAND_REG);
+ while
Re: More info on port 80 symptoms on MCP51 machine.
Allen Martin wrote: Nothing inside the chipset should be decoding port 80 writes. It's possible this board has a port 80 decoder wired onto the board that's misbehaving. I've seen other laptop boards with port 80 decoders wired onto the board, even if the 7 segment display is only populated on debug builds. This is very helpful. So the next question is there something on the laptop mainboard. Any idea how to look for such a thing? I am not averse to taking the laptop apart to look at the mainboard. -- 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 0/3] Add GD-Rom support to the SEGA Dreamcast
On Sun, 2007-12-16 at 00:20 +, Adrian McMenamin wrote: > (Apologies if you've already had this. I sent it to lkml etc an hour > ago but it just disappeated into the ether - trying it in smaller > packets this time.) > vger/lkml's spam filtering is trapping the main part of the patch as spam. Possibly because it has a lot of register names as capitals? I'll have to find some other way of putting it on the list. -- 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] alsa: fix SNDRV_PCM_IOCTL_TTSTAMP value.
"[ALSA] Use posix clock monotonic for PCM and timer timestamps" introduces
a bug that makes audio device unusable in some computers.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/include/sound/asound.h b/include/sound/asound.h
index 475eb71..d35aa44 100644
--- a/include/sound/asound.h
+++ b/include/sound/asound.h
@@ -443,7 +443,7 @@ enum {
enum {
SNDRV_PCM_IOCTL_PVERSION = _IOR('A', 0x00, int),
SNDRV_PCM_IOCTL_INFO = _IOR('A', 0x01, struct snd_pcm_info),
- SNDRV_PCM_IOCTL_TTSTAMP = _IOW('A', 0x03, int),
+ SNDRV_PCM_IOCTL_TTSTAMP = _IOW('A', 0x02, int),
SNDRV_PCM_IOCTL_HW_REFINE = _IOWR('A', 0x10, struct snd_pcm_hw_params),
SNDRV_PCM_IOCTL_HW_PARAMS = _IOWR('A', 0x11, struct snd_pcm_hw_params),
SNDRV_PCM_IOCTL_HW_FREE = _IO('A', 0x12),
--
Miguel Botó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/
Re: [PATCH] ARM: OMAP: Change mailing list for OMAP in MAINTAINERS
* Dirk Behme <[EMAIL PROTECTED]> [071214 22:48]: > > OMAP has now a list at vger. > > Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> > > Index: linux-osk/MAINTAINERS > === > --- linux-osk.orig/MAINTAINERS > +++ linux-osk/MAINTAINERS > @@ -3683,7 +3683,7 @@ S: Maintained > > TI OMAP MMC INTERFACE DRIVER > P: Carlos Aguiar, Anderson Briglia and Syed Khasim > -M: [EMAIL PROTECTED] (subscribers only) > +M: [EMAIL PROTECTED] > W: http://linux.omap.com > W: http://www.muru.com/linux/omap/ > S: Maintained > > Pushing today. Carlos, can you please add this to your upstream MMC patch series also? Regards, 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: [PATCH] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Here we go. # dmidecode -s baseboard-manufacturer Quanta # dmidecode -s baseboard-product-name 30B9 There do seem to be other systems, besides mine, that have the same problem. I think it's pretty likely that other machines that have this problem are Quanta machines, since Quanta is one of the primary ODM's that does HP laptops. Don't know about the product-name being common with the HP dv6000z family, which is another one reported to have this problem. We could try to ask all the reporters of hwclock freezes to report their results from dmidecode. Rene Herman wrote: On 15-12-07 21:27, H. Peter Anvin wrote: Rene Herman wrote: Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Uhm, no. You have no clue what the speed of the TSC is until you have been able to calibrate it against a fixed timesource - like the PIT. Yes. Hnng. Okay, this is going nowhere in a hurry, so back to the very first suggestion in this thread. How about this? This allows to switch from port 0x80 to port 0xed based on DMI. David: I plugged in my own DMI values for testing, but obviously yours are needed. The values that are needed are retrieved by the "dmidecode" program which you will probably have installed (it might be in an sbin directory) or will be able to install through whatever package manager you use. dmidecode -s baseboard-manufacturer dmidecode -s baseboard-product-name are the values you should plug into the .matches field in the dmi_system_id struct in this. It would be great if you could do that, test, and post back with those values. .ident should be a nice human name. It's been tested on x86-32 and seems to work fine. It's not been tested on x86-64 but seems to stand a fair chance of working similarly. It ofcourse remains possible to switch to a udelay() based method later on anyways but with all the pre-calibratin trouble, this might be the lowest risk method in the short run. This is partly based on previous patches by Pavel Machek and David P. Reed. I hope this is considered half-way correct/sane (note by the way that it's not a good idea to switch a "native_io_delay_port" value since plugging in a variable port would clobber register dx for every outb_p, which would then have to be reloaded for the next outb again). Comments appreciated. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> arch/x86/boot/compressed/misc_32.c |8 ++--- arch/x86/boot/compressed/misc_64.c |8 ++--- arch/x86/kernel/Makefile_32|2 - arch/x86/kernel/Makefile_64|2 - arch/x86/kernel/io_delay.c | 53 + arch/x86/kernel/setup_32.c |2 + arch/x86/kernel/setup_64.c |2 + include/asm-x86/io_32.h| 17 ++- include/asm-x86/io_64.h| 23 ++-- -- 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/3] Add GD-Rom support to the SEGA Dreamcast
diff -ruN ./linux-2.6-orig/drivers/block/Kconfig ./linux-2.6/drivers/block/Kconfig --- ./linux-2.6-orig/drivers/block/Kconfig 2007-12-15 22:23:47.0 + +++ ./linux-2.6/drivers/block/Kconfig 2007-12-15 22:18:28.0 + @@ -105,6 +105,18 @@ "MicroSolutions backpack protocol", "DataStor Commuter protocol" etc.). +config GDROM + tristate "SEGA Dreamcast GD-ROM drive" + depends on SH_DREAMCAST + help + A standard SEGA Dreamcast comes with a modified CD ROM drive called a + "GD-ROM" by SEGA to signify it is capable of reading special disks + with up to 1 GB of data. This drive will also read standard CD ROM + disks. Select this option to access any disks in you GD ROM drive. + Most users will want to say "Y" here. + You can also build this as a module - which will be called gdrom.ko + + source "drivers/block/paride/Kconfig" config BLK_CPQ_DA diff -ruN ./linux-2.6-orig/drivers/cdrom/Makefile ./linux-2.6/drivers/cdrom/Makefile --- ./linux-2.6-orig/drivers/cdrom/Makefile 2007-12-15 22:23:47.0 + +++ ./linux-2.6/drivers/cdrom/Makefile 2007-12-15 22:18:29.0 + @@ -11,3 +11,4 @@ obj-$(CONFIG_CDROM_PKTCDVD)+= cdrom.o obj-$(CONFIG_VIOCD)+= viocd.o cdrom.o +obj-$(CONFIG_GDROM)+= cdrom.o -- 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 3/3] Add GD-Rom support to the SEGA Dreamcast
diff -ruN ./linux-2.6-orig/drivers/sh/Makefile ./linux-2.6/drivers/sh/Makefile --- ./linux-2.6-orig/drivers/sh/Makefile2007-12-15 22:23:59.0 + +++ ./linux-2.6/drivers/sh/Makefile 2007-12-15 22:18:45.0 + @@ -4,3 +4,4 @@ obj-$(CONFIG_SUPERHYWAY) += superhyway/ obj-$(CONFIG_MAPLE)+= maple/ +obj-$(CONFIG_GDROM)+= gdrom/ -- 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 0/3] Add GD-Rom support to the SEGA Dreamcast
(Apologies if you've already had this. I sent it to lkml etc an hour ago but it just disappeated into the ether - trying it in smaller packets this time.) This patch adds support for the CD drive on the SEGA Dreamcast - the so-called GD Rom drive. This device is electrically compatible with ATA-3 IDE CD drives but implements a proprietary packet interface. There have been previous Dreamcast CD drivers around but this is new code and uses DMA as opposed to PIO for reads. It also supports reading the proprietary GD Rom format disks. The driver will live as drivers/sh/gdrom/gdrom.c This has been tested against the latest git in Paul Mundt's 2.6.25 queue as well as 2.6.24-rc5 Signed-off by: Adrian McMenamin <[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: 2.6.24-rc5-mm1: cat /proc/net/packet -> oops
Hello, As one of usual tests I run the following script: for i in `find /proc -type f`; do echo -n "cat $i > /dev/null ... "; cat $i > /dev/null; echo "done"; done This time the culprit is /proc/net/packet. cat process gets killed $ cat /proc/net/packet Segmentation fault and lost in lots of messages from the script but for some reason there is no info in syslog (why?). I could capture the oops only when issued sysrq-7 or grater. That's why I didn't catch the oops earlier. I found it because the bug makes my sparc64 box need a hardware reset most of the time it happens and produces oops 2 screens long. x86 kills the cat process but system is still usable and running fine. Bisection points to: git-ubi.patch GOOD # git-net.patch BAD ipsec-fix-reversed-icmp6-policy-check.patch but this seems to be far from precise :) $ grep ^commit git-net.patch | wc -l 361 Not sure if this is important but when bisecting the mm tree the oops got shorter at some point so maybe some other patch is also involved. This one is from x86: [ 194.508398] BUG: unable to handle kernel paging request at virtual address bd47 [ 194.508412] printing eip: c0135d59 *pde = [ 194.508419] Oops: [#1] PREEMPT [ 194.508424] last sysfs file: /devices/pci:00/:00:01.0/:01:05.0/resource [ 194.508428] Modules linked in: usbhid hid orinoco_cs orinoco hermes pcmcia firmware_class uhci_hcd ehci_hcd usbcore psmouse yenta_socket rsrc_nonstatic rtc 8139too [ 194.508443] [ 194.508447] Pid: 5368, comm: cat Not tainted (2.6.24-rc5 #9) [ 194.508450] EIP: 0060:[] EFLAGS: 00210046 CPU: 0 [ 194.508466] EIP is at __lock_acquire+0x5b/0xfc4 [ 194.508469] EAX: 0022 EBX: 00200246 ECX: bd43 EDX: 0002 [ 194.508472] ESI: bd43 EDI: EBP: d816ce80 ESP: d816ce14 [ 194.508475] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 194.508479] Process cat (pid: 5368, ti=d816c000 task=d826a000 task.ti=d816c000) [ 194.508481] Stack: c0135a21 d826a000 d816ce38 c0135697 d826a000 c0146ded [ 194.508490]c1304f98 0002 bd43 0001 d826a000 d816cec0 c013681d [ 194.508498]0006 0003 c03daa08 0001 0044 02ad 0005 [ 194.508506] Call Trace: [ 194.508508] [] show_trace_log_lvl+0x1a/0x30 [ 194.508518] [] show_stack_log_lvl+0xa5/0xca [ 194.508523] [] show_registers+0xcf/0x23f [ 194.508528] [] die+0x10d/0x1f5 [ 194.508532] [] do_page_fault+0x27e/0x5f0 [ 194.508540] [] error_code+0x6a/0x70 [ 194.508550] [] lock_acquire+0x5e/0x76 [ 194.508555] [] _read_lock+0x35/0x42 [ 194.508560] [] sock_i_ino+0x14/0x30 [ 194.508568] [] packet_seq_show+0x19/0xa0 [ 194.508576] [] seq_read+0x19a/0x29e [ 194.508583] [] proc_reg_read+0x57/0x78 [ 194.508590] [] vfs_read+0x89/0x11d [ 194.508596] [] sys_read+0x3d/0x64 [ 194.508600] [] sysenter_past_esp+0x5f/0xa5 [ 194.508605] === [ 194.508607] Code: c0 85 c0 0f 84 64 03 00 00 9c 58 f6 c4 02 0f 85 b8 07 00 00 83 ff 07 0f 87 de 07 00 00 85 ff 8d 76 00 0f 85 4f 03 00 00 8b 4d c0 <8b> 71 04 85 f6 0f 84 41 03 00 00 89 f0 e8 d8 d7 ff ff 85 c0 0f [ 194.508651] EIP: [] __lock_acquire+0x5b/0xfc4 SS:ESP 0068:d816ce14 [ 194.508660] note: cat[5368] exited with preempt_count 2 .config attached. Regards, Mariusz # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc5 # Sun Dec 16 00:22:27 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set
Re: [PATCH] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
H. Peter Anvin wrote: Note, however, that your code doesn't deal with io_delay()'s in the boot code (arch/x86/boot) at all, nor (obviously) io_delay()'s in boot loaders. In the boot code, access to DMI data is NOT available (we can't even use the INT 15h mover if we want to continue to support Loadlin.) Correction: DMI data are at least supposedly available via the PNPBIOS calls specified in the SMBIOS spec. -hpa -- 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/
broken suspend, sometimes (drm related) [Was: 2.6.24-rc5-mm1]
On 12/13/2007 11:40 AM, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
Broken @#$%^ suspend, again (and maybe still for a longer time). Unable to
reproduce this with netconsole.
trace led to i915_suspend
callpci_bus_read_config_byte#
movq8(%rbx), %rdi # .mmio_map, .mmio_map
movq24(%rdi), %rax # .handle, D.24395
movl458760(%rax), %eax #, D.24397
address in rax (i.e. dev_priv->mmio_map->handle) is broken, at least it seems so
from the part of the trace and RIP.
movl%eax, 408(%rbx) # D.24397, .savePIPEACONF
movq24(%rdi), %rax # .handle, temp.676
movl393244(%rax), %eax #, D.24399
in
pci_save_state(dev->pdev);
pci_read_config_byte(dev->pdev, LBB, _priv->saveLBB);
/* Pipe & plane A info */
--> dev_priv->savePIPEACONF = I915_READ(PIPEACONF);
I use distro pm-utils and it chvt's to some terminal, write out the output,
suspend, resume, switch back to X.
The patch I'm currently using for debugging:
Index: BH/drivers/char/drm/i915_drv.c
===
--- BH.orig/drivers/char/drm/i915_drv.c
+++ BH/drivers/char/drm/i915_drv.c
@@ -274,9 +274,18 @@ static int i915_suspend(struct drm_devic
return -ENODEV;
}
+ if (!dev_priv->mmio_map || !dev_priv->mmio_map->handle) {
+ printk(KERN_ERR "BAD BAD BAD %p %p\n", dev_priv->mmio_map,
+ dev_priv->mmio_map ? dev_priv->mmio_map->handle : NULL);
+ return -EIO;
+ }
+
pci_save_state(dev->pdev);
pci_read_config_byte(dev->pdev, LBB, _priv->saveLBB);
+ printk(KERN_ERR "\n\n\nmap %p, HANDLE: %p\n\n\n", dev_priv->mmio_map,
+ dev_priv->mmio_map->handle);
+ msleep(5000);
/* Pipe & plane A info */
dev_priv->savePIPEACONF = I915_READ(PIPEACONF);
dev_priv->savePIPEASRC = I915_READ(PIPEASRC);
Index: BH/drivers/char/drm/drm_bufs.c
===
--- BH.orig/drivers/char/drm/drm_bufs.c
+++ BH/drivers/char/drm/drm_bufs.c
@@ -136,6 +136,7 @@ static int drm_addmap_core(struct drm_de
return -EINVAL;
}
map->mtrr = -1;
+ printk("BLE %s a: map %p, handle %p\n", __func__, map, map->handle);
map->handle = NULL;
switch (map->type) {
@@ -183,6 +184,7 @@ static int drm_addmap_core(struct drm_de
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -ENOMEM;
}
+ printk("BLE %s b: map %p, handle %p\n", __func__, map, map->handle);
}
break;
@@ -201,6 +203,7 @@ static int drm_addmap_core(struct drm_de
return 0;
}
map->handle = vmalloc_user(map->size);
+ printk("BLE %s c: map %p, handle %p\n", __func__, map, map->handle);
DRM_DEBUG("%lu %d %p\n",
map->size, drm_order(map->size), map->handle);
if (!map->handle) {
@@ -211,6 +214,7 @@ static int drm_addmap_core(struct drm_de
if (map->flags & _DRM_CONTAINS_LOCK) {
/* Prevent a 2nd X Server from creating a 2nd lock */
if (dev->lock.hw_lock != NULL) {
+ printk("BLE %s d: map %p, handle %p\n", __func__, map, map->handle);
vfree(map->handle);
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EBUSY;
@@ -281,6 +285,7 @@ static int drm_addmap_core(struct drm_de
return -ENOMEM;
}
map->handle = dmah->vaddr;
+ printk("BLE %s f: map %p, handle %p\n", __func__, map, map->handle);
map->offset = (unsigned long)dmah->busaddr;
kfree(dmah);
break;
@@ -291,6 +296,7 @@ static int drm_addmap_core(struct drm_de
list = drm_alloc(sizeof(*list), DRM_MEM_MAPS);
if (!list) {
+ printk("BLE %s g: map %p, handle %p\n", __func__, map, map->handle);
if (map->type == _DRM_REGISTERS)
iounmap(map->handle);
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -308,6 +314,7 @@ static int drm_addmap_core(struct drm_de
map->offset;
ret = drm_map_handle(dev, >hash, user_token, 0);
if (ret) {
+ printk("BLE %s h: map %p, handle %p\n", __func__, map, map->handle);
if (map->type == _DRM_REGISTERS)
iounmap(map->handle);
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -355,6 +362,7 @@ int drm_addmap_ioctl(struct drm_device *
return err;
/* avoid a warning on 64-bit, this casting isn't very nice,
memory barriers and MMIO, once again...
Hi all, in a single thread of execution, writel() and friends are ordered WRT each other. But I keep forgetting one thing: Is writel() ordered WRT regular memory accesses? That is, if I prepare data in a coherent DMA buffer and then tell the device by writel() that it's good to go, do I need a wmb() before the writel()? *If* the answer to this is yes, then I also seem to need a wmb() between dma_sync_single_for_device() and writel() if that writel tells the device to use data from that synced DMA area, because the sync expands to empty inline functions on simple architectures. Or are there further ordering guarantees on these architectures which eliminate the need for a wmb() in this case? If so, would I still need a barrier()? Thanks, -- Stefan Richter -=-=-=== ==-- = http://arcgraph.de/sr/ -- 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] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: I hope this is considered half-way correct/sane (note by the way that it's not a good idea to switch a "native_io_delay_port" value since plugging in a variable port would clobber register dx for every outb_p, which would then have to be reloaded for the next outb again). Comments appreciated. That actually wouldn't be that big of a deal. Switching values in and out of registers is dirt cheap (and MUCH cheaper than an indirect function call) -- of course, if there is a reason to do it for paravirtualization then that's fine; we're talking about something that makes even the slowest CPU operation look speedy anyhow. If in*_p and out*_p are out-of-lined then %dx would be dead anyway, and so there is even less reason to deal with it. In theory we could use an alternatives section and patch the instruction, too; seems like way overkill, though. Note, however, that your code doesn't deal with io_delay()'s in the boot code (arch/x86/boot) at all, nor (obviously) io_delay()'s in boot loaders. In the boot code, access to DMI data is NOT available (we can't even use the INT 15h mover if we want to continue to support Loadlin.) In the boot code, io_delay() is used to slow down accesses to the KBC, interrupt controller, INT13h logic, and the NMI gate, and to provide a fixed delay during A20 stabilization. -hpa -- 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.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander
> + /* initialize cached registers from their original values */ > + pca9539_read_reg(chip, PCA9539_OUTPUT, >reg_output); > + pca9539_read_reg(chip, PCA9539_DIRECTION, >reg_direction); > + > + /* set platform specific polarity inversion */ > + pca9539_write_reg(chip, PCA9539_INVERT, pdata->invert); > + > + ret = pca9539_init_gpio(chip); > + if (ret) > + goto out_failed; I'm glad to see this patch no longer trashes previous chip state, but there's still an issue in that area. Surely the code should ret = pca9539_read_reg(...) if (ret) goto out_failed; and likewise for the write? If the chip isn't present (and thus an I/O error is reported), its probe() should fail. - 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/
[PATCH] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On 15-12-07 21:27, H. Peter Anvin wrote: Rene Herman wrote: Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Uhm, no. You have no clue what the speed of the TSC is until you have been able to calibrate it against a fixed timesource - like the PIT. Yes. Hnng. Okay, this is going nowhere in a hurry, so back to the very first suggestion in this thread. How about this? This allows to switch from port 0x80 to port 0xed based on DMI. David: I plugged in my own DMI values for testing, but obviously yours are needed. The values that are needed are retrieved by the "dmidecode" program which you will probably have installed (it might be in an sbin directory) or will be able to install through whatever package manager you use. dmidecode -s baseboard-manufacturer dmidecode -s baseboard-product-name are the values you should plug into the .matches field in the dmi_system_id struct in this. It would be great if you could do that, test, and post back with those values. .ident should be a nice human name. It's been tested on x86-32 and seems to work fine. It's not been tested on x86-64 but seems to stand a fair chance of working similarly. It ofcourse remains possible to switch to a udelay() based method later on anyways but with all the pre-calibratin trouble, this might be the lowest risk method in the short run. This is partly based on previous patches by Pavel Machek and David P. Reed. I hope this is considered half-way correct/sane (note by the way that it's not a good idea to switch a "native_io_delay_port" value since plugging in a variable port would clobber register dx for every outb_p, which would then have to be reloaded for the next outb again). Comments appreciated. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> arch/x86/boot/compressed/misc_32.c |8 ++--- arch/x86/boot/compressed/misc_64.c |8 ++--- arch/x86/kernel/Makefile_32|2 - arch/x86/kernel/Makefile_64|2 - arch/x86/kernel/io_delay.c | 53 + arch/x86/kernel/setup_32.c |2 + arch/x86/kernel/setup_64.c |2 + include/asm-x86/io_32.h| 17 ++- include/asm-x86/io_64.h| 23 ++-- commit 4a7e75776c648102488a89dbfad516448830ab1a Author: Rene Herman <[EMAIL PROTECTED]> Date: Sun Dec 16 00:24:32 2007 +0100 foo diff --git a/arch/x86/boot/compressed/misc_32.c b/arch/x86/boot/compressed/misc_32.c index b74d60d..288e162 100644 --- a/arch/x86/boot/compressed/misc_32.c +++ b/arch/x86/boot/compressed/misc_32.c @@ -276,10 +276,10 @@ static void putstr(const char *s) RM_SCREEN_INFO.orig_y = y; pos = (x + cols * y) * 2; /* Update cursor position */ - outb_p(14, vidport); - outb_p(0xff & (pos >> 9), vidport+1); - outb_p(15, vidport); - outb_p(0xff & (pos >> 1), vidport+1); + outb(14, vidport); + outb(0xff & (pos >> 9), vidport+1); + outb(15, vidport); + outb(0xff & (pos >> 1), vidport+1); } static void* memset(void* s, int c, unsigned n) diff --git a/arch/x86/boot/compressed/misc_64.c b/arch/x86/boot/compressed/misc_64.c index 6ea015a..43e5fcc 100644 --- a/arch/x86/boot/compressed/misc_64.c +++ b/arch/x86/boot/compressed/misc_64.c @@ -269,10 +269,10 @@ static void putstr(const char *s) RM_SCREEN_INFO.orig_y = y; pos = (x + cols * y) * 2; /* Update cursor position */ - outb_p(14, vidport); - outb_p(0xff & (pos >> 9), vidport+1); - outb_p(15, vidport); - outb_p(0xff & (pos >> 1), vidport+1); + outb(14, vidport); + outb(0xff & (pos >> 9), vidport+1); + outb(15, vidport); + outb(0xff & (pos >> 1), vidport+1); } static void* memset(void* s, int c, unsigned n) diff --git a/arch/x86/kernel/Makefile_32 b/arch/x86/kernel/Makefile_32 index a7bc93c..0cc1981 100644 --- a/arch/x86/kernel/Makefile_32 +++ b/arch/x86/kernel/Makefile_32 @@ -8,7 +8,7 @@ CPPFLAGS_vmlinux.lds += -Ui386 obj-y := process_32.o signal_32.o entry_32.o traps_32.o irq_32.o \ ptrace_32.o time_32.o ioport_32.o ldt_32.o setup_32.o i8259_32.o sys_i386_32.o \ pci-dma_32.o i386_ksyms_32.o i387_32.o bootflag.o e820_32.o\ - quirks.o i8237.o topology.o alternative.o i8253.o tsc_32.o + quirks.o i8237.o topology.o alternative.o i8253.o tsc_32.o io_delay.o obj-$(CONFIG_STACKTRACE) += stacktrace.o obj-y += cpu/ diff --git a/arch/x86/kernel/Makefile_64 b/arch/x86/kernel/Makefile_64 index 5a88890..08a68f0 100644 --- a/arch/x86/kernel/Makefile_64 +++ b/arch/x86/kernel/Makefile_64 @@ -11,7 +11,7 @@ obj-y := process_64.o signal_64.o entry_64.o traps_64.o irq_64.o \
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > Well, the only problem with that is I suspect there are some "newer" cards > that > work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) -- Greetings Michael. -- 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: New question on that sata controller
On Saturday 15 December 2007, Alistair John Strachan wrote: >On Saturday 15 December 2007 21:24:09 Gene Heskett wrote: >> On Saturday 15 December 2007, Robert Hancock wrote: >> >Gene Heskett wrote: >> >> Greetings; >> >> >> >> When I asked about a sata controller earlier this week, I gave a link >> >> to it. Unforch (maybe) when it actually arrived, the cards box showed a >> >> silicon image chip, and the card had a via. So much for getting what I >> >> ordered... >> >> >> >> The required module then was sata_via, not sata_uli, and it seems to be >> >> working ok. However, this one claims its a raid controller according >> >> to an lspci -v: >> >> >> >> 01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID >> >> Controller (rev 50) >> >> Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller >> >> Flags: bus master, medium devsel, latency 32, IRQ 19 >> >> I/O ports at 9400 [size=16] >> >> I/O ports at 9800 [size=16] >> >> I/O ports at 9c00 [size=16] >> >> I/O ports at a000 [size=16] >> >> I/O ports at a400 [size=32] >> >> I/O ports at a800 [size=256] >> >> [virtual] Expansion ROM at e900 [disabled] [size=64K] >> >> Capabilities: [e0] Power Management version 2 >> >> >> >> I just noted that the Expansion ROM is disabled, but I didn't see any >> >> jumpers to enable it on the card prior to installing it. Does anyone >> >> know how this is supposed to work? I would like to make it directly >> >> bootable but I believe this has to be 'enabled' for that. >> > >> >It's usually normal for it to be disabled after boot, I believe. Are you >> >getting anything showing up on boot indicating its BIOS is active? >> >> No, not a thing. Also invisible in the mainboards bios config AFAICT. > >Normally this option is called "Enable Option ROM" or enable "INT 13/19h >hook". See if you have such an option. It's surprising this isn't enabled by >default. I don't recall seeing such an option, but I'll look again when I next reboot. >However, the BIOS still might not support directly booting off the > controller, I'm afraid. I think I'm going to have to maintain my ide boot partition & play tricks with the kernel arguments line to make the switch to that drive after the kernel and initrd are loaded from it, which should make it properly visible oncve that kernel is running. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) His ideas of first-aid stopped short of squirting soda water. -- P.G. Wodehouse -- 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: [Bug 9182] Critical memory leak (dirty pages)
On Sat, 15 Dec 2007, [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9182 --- Comment #33 from [EMAIL PROTECTED] 2007-12-15 14:19 --- Krzysztof, I'd hate point you to a hard path (at least time consuming), but you've done a lot of digging by now anyway. How about git bisecting between 2.6.20-rc2 and rc1? Here is great info on bisecting: http://www.kernel.org/doc/local/git-quick.html As I'm smarter than git-bistect I can tell that 2.6.20-rc1-git8 is as bad as 2.6.20-rc2 but 2.6.20-rc1-git8 with one patch reverted seems to be OK. So it took me only 2 reboots. ;) The guilty patch is the one I proposed just an hour ago: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.20.y.git;a=commitdiff_plain;h=fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 So: - 2.6.20-rc1: OK - 2.6.20-rc1-git8 with fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 reverted: OK - 2.6.20-rc1-git8: very BAD - 2.6.20-rc2: very BAD - 2.6.20-rc4: very BAD - >= 2.6.20: BAD (but not *very* BAD!) Best regards, Krzysztof Olędzki
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Saturday, 15 of December 2007, John W. Linville wrote: > On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > > On Friday, 14 of December 2007, Michael Buesch wrote: > > > > Either distributions have to install it automatically or people simply > > > have > > > to read one or two lines of documentation. That's just what I wanted to > > > say. > > > > It's not that simple. For example, regression testing will be a major PITA > > if one needs to switch back and forth from the new driver to the old one in > > the > > process. > > Not really true -- a single system can easily have firmware installed > for b43, b43legacy, and bcm43xx at the same time and switch back and > forth between them. > > Given a functioning udev configuration, the persistent naming even > works so that your device stays as 'eth1' when switching to and > fro bcm43xx. Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-) > I really think everyone is overstating the problem. You might be right. Greetings, Rafael -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Pavel Machek wrote: this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. No kidding! We're talking about removing a hack that has been successful on thousands of pieces of hardware over 15 years because it breaks ONE machine. If this should be done at all it should be done in the most careful manner possible. 2.6.25 would be an aggressive schedule. -hpa -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 14:15:03, Ingo Molnar wrote: > > * David P. Reed <[EMAIL PROTECTED]> wrote: > > > Replace use of outb to "unused" diagnostic port 0x80 for time delay > > with udelay based time delay on x86_64 architecture machines. Fix for > > bugs 9511 and 6307 in bugzilla, plus bugs reported in > > bugzilla.redhat.com. > > > > Derived from suggestion (that didn't compile) by Pavel Machek, and > > tested, also based on measurements of typical timings of out's > > collated by Rene Herman from many in the community. > > > > This patch fixes a number of bugs known to cause problems on HP > > Pavilion dv9000z and dv6000z laptops - in the form of solid freezes > > when hwclock is used to show or set the time. Also, it potentially > > improves bus utilization on SMP machines, by using a waiting process > > that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds. > > > > i386 family fixes (completely parallel) were not included, considering > > that such machines might involve more risk of problems on legacy > > machines. > > wow, cool fix! (I remember that there were other systems as well that > are affected by port 0x80 muckery - i thought we had removed port 0x80 > accesses long ago.) > > how about the simpler fix below, as a first-level approach? We can then > remove the _p in/out sequences after this. > > this is also something for v2.6.24 merging. As much as I like this patch, I do not think it is suitable for .24. Too risky, I'd say. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Saturday, 15 of December 2007, Michael Buesch wrote: > On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: > > On Friday, 14 of December 2007, Michael Buesch wrote: > > > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > > > > This user did get the following messages in dmesg: > > > > > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > > > >"or load failed.\n", path); > > > > > > > > So the question seems to be why b43 needs version 4, when b43legacy and > > > > bcm43x uses version 3? > > > > > > That's really a question, right? > > > > > > Well. linux-2.4 doesn't work with the linux-2.6 modutils. > > > Windows Vista doesn't work with Windows 98 device drivers. > > > That leads to this assumption: > > > b43 doesn't work with version 3 firmware but needs version 4. > > > > > > Newer drivers supporting newer hardware need newer firmware. > > > > Actually, can you explain why, from the technical point of view, the > > version 4 > > firware is better than version 3, please? > > version 4 is the new firmware released by broadcom. They obviously won't > support and write any version 3 firmware anymore. So we are forced to > switch to version 4 firmware to support the newest hardware (like N-PHY > in the future). It's really as simple as that. I see, thanks. > The difference between v3 and v4 is basically the driver API. It changed > a lot and it is nontrivial to support both v3 and v4 in one driver. > So we decided to stay with v3 for legacy devices and take v4 for any newer > devices. This is reasonable, yes. > We have to live with that crap until someone comes up with an opensource > firmware. :) Well, the only problem with that is I suspect there are some "newer" cards that work better with v3 firmware, although they are supposed to support both. Greetings, Rafael -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri 2007-12-14 15:23:55, Ingo Molnar wrote: > > * Rene Herman <[EMAIL PROTECTED]> wrote: > > > --- a/init/main.c > > +++ b/init/main.c > > @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line) > > } > > > > /* > > - * This should be approx 2 Bo*oMips to start (note initial shift), and will > > - * still work even if initially too large, it will just take slightly > > longer > > + * Initial value roughly corresponds to a 1 GHz CPU > > */ > > -unsigned long loops_per_jiffy = (1<<12); > > +unsigned long loops_per_jiffy = 10 / HZ; > > > > EXPORT_SYMBOL(loops_per_jiffy); > > this is a factor of ~2400 increase - this will take an eternity to boot > on any older CPU. I don't think we are using outb_p before loops_per_jiffy are initialized -- I believe I'd see oopsen if we did. Factor 2400 increase is bad, but if it only converts 10x 1usec delay into 10x 24msec delay, it is not _that_ bad. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Sat 2007-12-15 12:26:26, H. Peter Anvin wrote: > Paul Rolland wrote: >> Just an idea : from what I've read, the problem (port 80 hanging) only >> occurs >> on 'modern' machines... > > It happens on *one single* "modern" machine... > > Let's keep that in perspective. it hurts on other machines (like debug leds being useless), and it may be incorrect as soon as you insert leds-on-port-0x80-on-PCI card. No, it is not critical but yes, I'd like to see it fixed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 4/8] unify paravirt parts of system.h
On Sat 2007-12-15 14:26:38, Andi Kleen wrote: > > It probably is safe to remove... but we currently support '2.8.95 > > kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses > > cr8. > > No it won't. 2.8 would just restore some random useless value. Restoring random value seems wrong. Putting random values into cpu registers can break stuff, right? Even if 2.6.24 image being restored did not set %cr8 itself, it may depend on %cr8 to have "sane" value. > If 2.8 wants to use CR8 it would have to re-initialize it We are talking "2.8 restores 2.6 image" here. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: More info on port 80 symptoms on MCP51 machine.
Allen Martin wrote: Nothing inside the chipset should be decoding port 80 writes. It's possible this board has a port 80 decoder wired onto the board that's misbehaving. I've seen other laptop boards with port 80 decoders wired onto the board, even if the 7 segment display is only populated on debug builds. We use PCI port 80 decoders internally for debugging quite often, so if there were some chipset issue related to port 80 it would have showed up a long time ago, and this is the first I've heard of hangs related to port 80 writes. Presumably you have programmable decoders to trigger SMI? If not, then they're probably doing the equivalent in a SuperIO chip or similar. -hpa -- 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: /dev/urandom uses uninit bytes, leaks user data
>> There is a path that goes from user data into the pool. This path >> is subject to manipulation by an attacker, for both reading and >> writing. Are you going to guarantee that in five years nobody >> will discover a way to take advantage of it? Five years ago >> there were no public attacks against MD5 except brute force; >> now MD5 is on the "weak" list. > Yep, I'm confident about making such a guarantee. Very confident. For the writing side, there's a far easier way to inject potentially hostile data into the /dev/random pool: "echo evil inentions > /dev/random". This is allowed because it's a very specific design goal that an attacker cannot improve their knowledge of the state of the pool by feeding in chosen text. Which in turn allows /dev/random to get potential entropy from lots of sources without worrying about how good they are. It tries to account for entropy it's sure of, but it actually imports far more - it just don't know how much more. One of those "allowed, but uncredited" sources is whatever you want to write to /dev/random. So you can, if you like, get seed material using wget -t1 -q --no-cache -O /dev/random 'http://www.fourmilab.ch/cgi-bin/Hotbits?fmt=bin=32' 'http://www.random.org/cgi-bin/randbyte?nbytes=32=f' 'http://www.randomnumbers.info/cgibin/wqrng.cgi?limit=255=32' 'http://www.lavarnd.org/cgi-bin/randdist.cgi?pick_num=16_num=65536' I don't trust them, but IF the data is actually random, and IF it's not observed in transit, then that's four nice 256-bit random seeds. (Note: if you actually use the above, be very careful not to abuse these free services by doing it too often. Also, the latter two actually return whole HTML pages with the numbers included in ASCII. If anyone knows how to just download raw binary, please share.) -- 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: More info on port 80 symptoms on MCP51 machine.
> Alan Cox wrote: > > On Wed, 12 Dec 2007 21:58:25 +0100 > > Rene Herman <[EMAIL PROTECTED]> wrote: > > > >> On 12-12-07 21:26, Rene Herman wrote: > >> > >>> On 12-12-07 21:07, David P. Reed wrote: > Someone might have an in to nVidia to clarify this, > since I don't. > In any case, the udelay(2) approach seems to be a safe > fix for this machine. > >> By the way, _does_ anyone have a contact at nVidia who > could clarify? > >> Alan maybe? I'm quite curious what they did... > > > > I don't. Nvidia are not the most open bunch of people on > the planet. > > This doesn't appear to be a chipset bug anyway but a firmware one > > (other systems with the same chipset work just fine). > > > > The laptop maker might therefore be a better starting point. > > One wonders if it does some SMM trick to capture port 0x80 > writes and attempt to haul them off for debugging; it almost > sounds like some kind of debugging code got let out into the field. > > -hpa Nothing inside the chipset should be decoding port 80 writes. It's possible this board has a port 80 decoder wired onto the board that's misbehaving. I've seen other laptop boards with port 80 decoders wired onto the board, even if the 7 segment display is only populated on debug builds. We use PCI port 80 decoders internally for debugging quite often, so if there were some chipset issue related to port 80 it would have showed up a long time ago, and this is the first I've heard of hangs related to port 80 writes. -Allen --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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] dynamic pipe resizing
On Saturday 15 December 2007, Jan Engelhardt wrote: > On Aug 24 2007 10:52, Jens Axboe wrote: > >Subject: [PATCH][RFC] dynamic pipe resizing > >Like with my original splice patches from 2005, I used fcntl() > >F_GETPIPE_SZ and F_SETPIPE_SZ to change the size of the pipe. I'm not > >particularly fond of that interface, so suggestions on how to improve it > >would be appreciated. Even if fcntl() should be the preferred approach, > >I think it would be better to pass in a byte based value instead of a > >number of pages. > > > Could this patch still make it in? > Yes, I think its set() and get() parts should use bytes and convert > to/from pages. > > Perhaps just round up, and mention the rounding in the manpage, so that > noone gets a shock when the pipe is not exactly as small as requested. Yes, but document only that it is rounding and make the unit arbitrary. That reduces the ABI requirements. Best Regards Ingo Oeser -- 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: New question on that sata controller
On Saturday 15 December 2007 21:24:09 Gene Heskett wrote: > On Saturday 15 December 2007, Robert Hancock wrote: > >Gene Heskett wrote: > >> Greetings; > >> > >> When I asked about a sata controller earlier this week, I gave a link to > >> it. Unforch (maybe) when it actually arrived, the cards box showed a > >> silicon image chip, and the card had a via. So much for getting what I > >> ordered... > >> > >> The required module then was sata_via, not sata_uli, and it seems to be > >> working ok. However, this one claims its a raid controller according to > >> an lspci -v: > >> > >> 01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID > >> Controller (rev 50) > >> Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller > >> Flags: bus master, medium devsel, latency 32, IRQ 19 > >> I/O ports at 9400 [size=16] > >> I/O ports at 9800 [size=16] > >> I/O ports at 9c00 [size=16] > >> I/O ports at a000 [size=16] > >> I/O ports at a400 [size=32] > >> I/O ports at a800 [size=256] > >> [virtual] Expansion ROM at e900 [disabled] [size=64K] > >> Capabilities: [e0] Power Management version 2 > >> > >> I just noted that the Expansion ROM is disabled, but I didn't see any > >> jumpers to enable it on the card prior to installing it. Does anyone > >> know how this is supposed to work? I would like to make it directly > >> bootable but I believe this has to be 'enabled' for that. > > > >It's usually normal for it to be disabled after boot, I believe. Are you > >getting anything showing up on boot indicating its BIOS is active? > > No, not a thing. Also invisible in the mainboards bios config AFAICT. Normally this option is called "Enable Option ROM" or enable "INT 13/19h hook". See if you have such an option. It's surprising this isn't enabled by default. However, the BIOS still might not support directly booting off the controller, I'm afraid. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- 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: Next patches for the 2.6.25 queue
On Fri, Dec 14, 2007 at 11:43:35AM -0500, Mathieu Desnoyers wrote: > * Adrian Bunk ([EMAIL PROTECTED]) wrote: > > On Thu, Dec 13, 2007 at 09:46:42AM -0500, Mathieu Desnoyers wrote: > > > Hi Andrew, > > > > > > I would like to post my next patches in a way that would make it as > > > easy for you and the community to review them. Currently, the patches > > > that have really settled down are : > > > > > > * For 2.6.25 > > >... > > > - Immediate Values > > > - Redux version, asked by Rusty > > >... > > > > I might have missed it: > > > > Are there any real numbers (opposed to estimates and microbenchmarks) > > available how much performance we actually gain in which situations? > > > > It might be some workload with markers using Immediate Values or > > something like that, but it should be something where the kernel > > runs measurably faster with Immediate Values than without. > > > > Currently I'm somewhere between "your Immediate Values are just an > > academic code obfuscation without any gain in practice" and "janitors > > should convert all drivers to use Immediate Values", and I'd like to > > form an opinion based on in which situations the kernel runs faster by > > how many percent. > > > > That's also based on observation like e.g. that __read_mostly should > > improve the performance, but I've already seen situations in the kernel > > where it forced gcc to emit code that was obviously both bigger and > > slower than without the __read_mostly [1], and that's part of why I'm > > sceptical of all optimizations below the C level unless proven > > otherwise. > > > > Hi Adrian, Hi Mathieu, > Yes, I had numbers that were presented in the patch headers, but I > re-ran some tests to have a clearer picture. Actually, what makes this > difficult to benchmark is the measurement error caused by the system's > "background noise" (interrupts, softirqs, kernel threads...). Note that > we are measuring cache effects and, therefore, any program which does > the same operation many times in a loop will benefit from space and time > locality and won't trigger many cache misses after the first loop. > > So, here is what I have done to get a significant difference between the > with and without immediate values : > > I ran, in userspace, a program that does random memory access > (3 times, in a 10MB array) between each getppid() syscall, everything > wrapped in a loop, repeated 1000 times (enough so the results are > reproduceable between runs). Tests were done on a 3GHz Pentium 4 with > 2GB of ram with Linux 2.6.24-rc5. gcc version? > I instrumented getppid() with 40 markers, so the impact of memory reads > won't be burried in the "background noise". Since each markers is using > a 24 bytes structure (8 bytes aligned), and are next to each other in > memory, we will cause (depending on the alignment of structures in the > cache lines) : > > L1 cache lines : 64 bytes > L2 cache lines : 128 bytes > > 8-9 memory reads (L2 cache misses) > 15-16 L2 accesses (L1 cache misses) > > for each getppid() syscall. > > The result is as expected : > > Number of cycles for getppid > > * Without memory pressure : 1470 cycles > * With memory pressure (std. dev. calculated on 3 groups of 1000 loops on > compiled out case : 416.54 cycles) > * 40 markers without immediate values : 14938 cycles > * 40 markers with immediate values :12795 cycles > * Markers compiled out :12427 cycles > > for a 14% speedup reached by using immediate values of data reads. > There seems to be no significant difference between compiling out the > markers and using immediate values to disable them. OK, it's good to see that there are situations where we can measure the benefits. > Note that since the markers are located in the same cache lines, those > 40 markers are the equivalent to have about 8 markers _not_ on the same > cache lines (in real life, that's very likely to be the case). > > So, the conditions to have a speedup here : > > - A significant amount of cache lines must be saved. > - They must be read from memory often. > > So, we will likely see a real-life impact in situations such as : > instrumenting spinlocks; whenever they would be taken/released many > times in a system call made by an application doing random memory access > (a hash-based search engine would be a good example, a database would > also be a suitable workload), we should be able to measure the impact. > However, this is hard to reproduce/measure, so this is why I created a > synthetic workload simulating this behavior. > > So I would really suggest using the immediate values for applications > such as : > - code markup (the markers) > - dynamically enable what would have otherwise been selected in > menuconfig (such as profiling, scheduler/timer statistics for > powertop...) > > where the goal is to have _zero_ measurable impact on performance on any > workload. Are the effects of
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > On Friday, 14 of December 2007, Michael Buesch wrote: > > Either distributions have to install it automatically or people simply have > > to read one or two lines of documentation. That's just what I wanted to > > say. > > It's not that simple. For example, regression testing will be a major PITA > if one needs to switch back and forth from the new driver to the old one in > the > process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. I really think everyone is overstating the problem. John -- John W. Linville [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/
problem with ending requests asynchronously in my block device driver
Hi,
I've a block device driver which does the following,
Inside the request function I do something like this:
request(fn) {
while ((req = elv_next_request(q)) != NULL) {
set up the request;
spin_unlock_irq(q->queue_lock);
call the transfer(set_up_req) function;
spin_lock_irq(q->queue_lock);
}
spin_unlock_irq (q->queue_lock);
/* allow callback to execute as it needs the lock!!! */
spin_lock_irq (q->queue_lock);
}
and the transfer function calls the scsi_execute_asyn() with the
callback function doing the end request. So, the ending of the request is
done like below:
callback(fn) {
spin_lock_irqsave(q->queue_lock, flags);
if (!end_that_request_first(set_up_req->req, cmpstatus,
set_up_req->req->nr_sectors)) {
add_disk_randomness(...);
end_that_request_last(set_up_req->req,0);
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen
Please help me to find out where I'm going wrong?
when I say 'fails' it just hangs without any error I'm using dt(Data
test) to write to the disk. The logs show that all the requests that have
been sent for processing, have completed sucessfully. Its just that new
requests never enter the request function. So, the dt writes almost half the
data and then simply hangs.
Thanks in advance for an early reply.
Anil P.
--
View this message in context:
http://www.nabble.com/problem-with-ending-requests-asynchronously-in-my-block-device-driver-tp14355561p14355561.html
Sent from the linux-kernel mailing list archive at Nabble.com.
--
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: [Bug 9182] Critical memory leak (dirty pages)
http://bugzilla.kernel.org/show_bug.cgi?id=9182 On Sat, 15 Dec 2007, Krzysztof Oledzki wrote: On Thu, 13 Dec 2007, Krzysztof Oledzki wrote: On Thu, 13 Dec 2007, Peter Zijlstra wrote: On Thu, 2007-12-13 at 16:17 +0100, Krzysztof Oledzki wrote: BTW: Could someone please look at this problem? I feel little ignored and in my situation this is a critical regression. I was hoping to get around to it today, but I guess tomorrow will have to do :-/ Thanks. So, its ext3, dirty some pages, sync, and dirty doesn't fall to 0, right? Not only doesn't fall but continuously grows. Does it happen with other filesystems as well? Don't know. I generally only use ext3 and I'm afraid I'm not able to switch this system to other filesystem. What are you ext3 mount options? /dev/root / ext3 rw,data=journal 0 0 /dev/VolGrp0/usr /usr ext3 rw,nodev,data=journal 0 0 /dev/VolGrp0/var /var ext3 rw,nodev,data=journal 0 0 /dev/VolGrp0/squid_spool /var/cache/squid/cd0 ext3 rw,nosuid,nodev,noatime,data=writeback 0 0 /dev/VolGrp0/squid_spool2 /var/cache/squid/cd1 ext3 rw,nosuid,nodev,noatime,data=writeback 0 0 /dev/VolGrp0/news_spool /var/spool/news ext3 rw,nosuid,nodev,noatime,data=ordered 0 0 BTW: this regression also exists in 2.6.24-rc5. I'll try to find when it was introduced but it is hard to do it on a highly critical production system, especially since it takes ~2h after a reboot, to be sure. However, 2h is quite good time, on other systems I have to wait ~2 months to get 20MB of leaked memory: # uptime 13:29:34 up 58 days, 13:04, 9 users, load average: 0.38, 0.27, 0.31 # sync;sync;sleep 1;sync;grep Dirt /proc/meminfo Dirty: 23820 kB More news, I hope this time my problem get more attention from developers since now I have much more information. So far I found that: - 2.6.20-rc4 - bad: http://bugzilla.kernel.org/attachment.cgi?id=14057 - 2.6.20-rc2 - bad: http://bugzilla.kernel.org/attachment.cgi?id=14058 - 2.6.20-rc1 - OK (probably, I need to wait little more to be 100% sure). 2.6.20-rc1 with 33m uptime: ~$ grep Dirt /proc/meminfo ;sync ; sleep 1 ; sync ; grep Dirt /proc/meminfo Dirty: 10504 kB Dirty: 0 kB 2.6.20-rc2 was released Dec 23/24 2006 (BAD) 2.6.20-rc1 was released Dec 13/14 2006 (GOOD?) It seems that this bug was introduced exactly one year ago. Surprisingly, dirty memory in 2.6.20-rc2/2.6.20-rc4 leaks _much_ more faster than in 2.6.20-final and later kernels as it took only about 6h to reach 172MB. So, this bug might be cured afterward, but only a little. There are three commits that may be somehow related: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=commitdiff;h=fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=commitdiff;h=3e67c0987d7567ad41164a153dca9a43b11d http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=commitdiff;h=5f2a105d5e33a038a717995d2738434f9c25aed2 I'm going to check 2.6.20-rc1-git... releases but it would be *very* nice if someone could finally give ma a hand and point some hints helping debugging this problem. Please note that none of my systems with kernels >= 2.6.20-rc1 is able to reach 0 kb of dirty memory, even after many synces, even when idle. Best regards, Krzysztof Olędzki
Re: New question on that sata controller
On Saturday 15 December 2007, Robert Hancock wrote: >Gene Heskett wrote: >> Greetings; >> >> When I asked about a sata controller earlier this week, I gave a link to >> it. Unforch (maybe) when it actually arrived, the cards box showed a >> silicon image chip, and the card had a via. So much for getting what I >> ordered... >> >> The required module then was sata_via, not sata_uli, and it seems to be >> working ok. However, this one claims its a raid controller according to >> an lspci -v: >> >> 01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID >> Controller (rev 50) >> Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller >> Flags: bus master, medium devsel, latency 32, IRQ 19 >> I/O ports at 9400 [size=16] >> I/O ports at 9800 [size=16] >> I/O ports at 9c00 [size=16] >> I/O ports at a000 [size=16] >> I/O ports at a400 [size=32] >> I/O ports at a800 [size=256] >> [virtual] Expansion ROM at e900 [disabled] [size=64K] >> Capabilities: [e0] Power Management version 2 >> >> I just noted that the Expansion ROM is disabled, but I didn't see any >> jumpers to enable it on the card prior to installing it. Does anyone know >> how this is supposed to work? I would like to make it directly bootable >> but I believe this has to be 'enabled' for that. > >It's usually normal for it to be disabled after boot, I believe. Are you >getting anything showing up on boot indicating its BIOS is active? No, not a thing. Also invisible in the mainboards bios config AFAICT. >> I cannot find any references to this particular chip in a 'make xconfig' >> for 2.6.24-rc5. >> >> Should this be a concern, or is this one a 'Just Works(TM)' chipset? This >> card has 3 sata port connectors and one ide fitted. >> >> Two rather pleasant side effects of going to the Biostar.tw site and >> finding a newer bios and installing it on an M7NCD Pro mobo are: >> >> 1: FSB now running at 400MHZ, was 333 before as it was not at all stable >> at 400 and I have been told the XP-2800 Athlon only supports 333 and AMD's >> site agrees. >> >> 2: CPU temps are down around 13F. CPU speed still the same at 2079MHZ >> according to dmesg. >> >> The reduced temps at a higher FSB indicates better interface timing, and >> if it runs the rest of the night at 400 without a self reboot or crash, >> I'll leave it there. Running at 400 FSB it gradually ate itself and turned into a brick. Took about 3 hours of screwing around to recover cuz even a cmos reset left it 400 and it wouldn't recognize my usb keyboard, so I had to dig out an IBM clickity clakker, one of those cast iron models & plug it into the ps2 socket to get its attention and get back into the bios and get it slowed down. This must have been good though cuz the cpu went down another 5 degrees when I did. I did another install of F8 on that drive, but on the reboot, only FC6 on /dev/hda1(=/boot and hda3=/) were visible so I'm still on FC6. This is with a bios release only about 90 days old for what can best be described as a legacy mobo, a Biostar M7NCD Pro. No onboard sata or firewire. The install did put its bootfile stuff on /dev/sda1, and I've copied them back to the FC6 /boot partition, but I am confused as to how to handle the differences for this in the kernel arguments I use in adding that stanza to the existing /boot/grub/grub.conf, and, what to do with the differences in /boot/grub/device.map between the 2 installs. Some guidance with this regard would be nice. FWIW, the f8 install is on VolGroup01, so it does know the difference, but udev did NOT generate those files in /dev when it ran, so I'm reticent to do a fix there by any method but editing some udev file somehow so its permanent once done. Thanks Robert. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "Don't discount flying pigs before you have good air defense." -- [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/
problem with ending requests asynchronously in my block device driver
Hi,
I've a block device driver which does the following,
Inside the request function I do something like this:
request(fn) {
while ((req = elv_next_request(q)) != NULL) {
set up the request;
spin_unlock_irq(q->queue_lock);
call the transfer(set_up_req) function;
spin_lock_irq(q->queue_lock);
}
spin_unlock_irq (q->queue_lock);
/* allow callback to execute as it needs the lock!!! */
spin_lock_irq (q->queue_lock);
}
and the transfer function calls the scsi_execute_asyn() with the
callback function doing the end request. So, the ending of the request is
done like below:
callback(fn) {
spin_lock_irqsave(q->queue_lock, flags);
if (!end_that_request_first(set_up_req->req, cmpstatus,
set_up_req->req->nr_sectors)) {
add_disk_randomness(...);
end_that_request_last(set_up_req->req,0);
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen
Please help me to find out where I'm going wrong?
Thanks in advance for an early reply.
Anil P.
--
View this message in context:
http://www.nabble.com/problem-with-ending-requests-asynchronously-in-my-block-device-driver-tp14355076p14355076.html
Sent from the linux-kernel mailing list archive at Nabble.com.
--
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: New question on that sata controller
Gene Heskett wrote: Greetings; When I asked about a sata controller earlier this week, I gave a link to it. Unforch (maybe) when it actually arrived, the cards box showed a silicon image chip, and the card had a via. So much for getting what I ordered... The required module then was sata_via, not sata_uli, and it seems to be working ok. However, this one claims its a raid controller according to an lspci -v: 01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50) Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at 9400 [size=16] I/O ports at 9800 [size=16] I/O ports at 9c00 [size=16] I/O ports at a000 [size=16] I/O ports at a400 [size=32] I/O ports at a800 [size=256] [virtual] Expansion ROM at e900 [disabled] [size=64K] Capabilities: [e0] Power Management version 2 I just noted that the Expansion ROM is disabled, but I didn't see any jumpers to enable it on the card prior to installing it. Does anyone know how this is supposed to work? I would like to make it directly bootable but I believe this has to be 'enabled' for that. It's usually normal for it to be disabled after boot, I believe. Are you getting anything showing up on boot indicating its BIOS is active? I cannot find any references to this particular chip in a 'make xconfig' for 2.6.24-rc5. Should this be a concern, or is this one a 'Just Works(TM)' chipset? This card has 3 sata port connectors and one ide fitted. Two rather pleasant side effects of going to the Biostar.tw site and finding a newer bios and installing it on an M7NCD Pro mobo are: 1: FSB now running at 400MHZ, was 333 before as it was not at all stable at 400 and I have been told the XP-2800 Athlon only supports 333 and AMD's site agrees. 2: CPU temps are down around 13F. CPU speed still the same at 2079MHZ according to dmesg. The reduced temps at a higher FSB indicates better interface timing, and if it runs the rest of the night at 400 without a self reboot or crash, I'll leave it there. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- 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/
problem with ending requests asynchronously in my block device driver
Hi,
I've a block device driver which does the following,
Inside the request function I do something like this:
request(fn) {
while ((req = elv_next_request(q)) != NULL) {
set up the request;
spin_unlock_irq(q->queue_lock);
call the transfer(set_up_req) function;
spin_lock_irq(q->queue_lock);
}
spin_unlock_irq (q->queue_lock);
/* allow callback to execute as it needs the lock!!! */
spin_lock_irq (q->queue_lock);
}
and the transfer function calls the scsi_execute_asyn() with the
callback function doing the end request. So, the ending of the request is
done like below:
callback(fn) {
spin_lock_irqsave(q->queue_lock, flags);
if (!end_that_request_first(set_up_req->req, cmpstatus,
set_up_req->req->nr_sectors)) {
add_disk_randomness(...);
end_that_request_last(set_up_req->req,0);
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen
Please help me to find out where I'm going wrong?
Thanks in advance for an early reply.
Anil P.
--
View this message in context:
http://www.nabble.com/problem-with-ending-requests-asynchronously-in-my-block-device-driver-tp14354996p14354996.html
Sent from the linux-kernel mailing list archive at Nabble.com.
--
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 4/8] unify paravirt parts of system.h
Pavel Machek wrote: It probably is safe to remove... but we currently support '2.8.95 kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses cr8. So please keep it if it is not a big problem. Note that CR8 is an alias for the TPR in the APIC. -hpa -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Paul Rolland wrote: Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... It happens on *one single* "modern" machine... Let's keep that in perspective. -hpa -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: Yes, just posted a Patch-For-Comments that switches on the availability of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that only really old stuff would be using the outb still. A TSC is really all we need to have a sensible udelay(). Uhm, no. You have no clue what the speed of the TSC is until you have been able to calibrate it against a fixed timesource - like the PIT. -hpa -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Rene Herman wrote: It's really going to have to be a known _un_used register and (the write direction of) port 0x80 is used exactly for that reason. Port 0xed is a known "alternate diagnostic port" used by Phoenix BIOSes at least but Peter Anvin reported trouble with that one -- probably for the outb direction but assuming that means something was in fact responding, we'd have the same timing problem. Yes, for the outbound direction. I believe we have two "good" options: 1) port 0xed was tested by the current reporter and found to be safe (and provide slow enough timing). If DMI based quirk hacks are available soon enough we can switch 0x80 to 0xed based on it. Are they? DMI is just a data structure parked in memory, so it should at least be theoretically possible to get to it. -hpa -- 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: ATA bus error with external hd on esata
Zsolt Barat schrieb: > hi list, > i just bought a "MyBook" called external HD with a fixed enclosure, from > WD. Connected to the SATA port i constantly get "ATA bus error" messages > in the kernel log. Is this a known issue? > > /var/log/messages: > Dec 15 18:37:53 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 > action 0x2 > Dec 15 18:37:53 proto1 ata2.00: irq_stat 0x4001 > Dec 15 18:37:53 proto1 ata2.00: cmd 35/00:e0:a7:d2:01/00:01:33:00:00/e0 > tag 0 cdb 0x0 data 245760 out > Dec 15 18:37:53 proto1 res 51/84:00:86:d4:01/00:00:33:00:00/e0 Emask > 0x10 (ATA bus error) > Dec 15 18:37:54 proto1 ata2: soft resetting port > Dec 15 18:37:54 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl > 310) > Dec 15 18:37:54 proto1 ata2.00: configured for UDMA/33 > Dec 15 18:37:54 proto1 ata2: EH complete > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware > sectors (500108 MB) > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write Protect is off > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read > cache: enabled, doesn't support DPO or FUA > Dec 15 18:38:15 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 > action 0x2 > Dec 15 18:38:15 proto1 ata2.00: irq_stat 0x4001 > Dec 15 18:38:15 proto1 ata2.00: cmd 35/00:80:bf:09:14/00:01:33:00:00/e0 > tag 0 cdb 0x0 data 196608 out > Dec 15 18:38:15 proto1 res 51/84:00:3e:0b:14/00:00:33:00:00/e0 Emask > 0x10 (ATA bus error) > Dec 15 18:38:15 proto1 ata2: soft resetting port > Dec 15 18:38:15 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl > 310) > Dec 15 18:38:15 proto1 ata2.00: configured for UDMA/33 > Dec 15 18:38:15 proto1 ata2: EH complete > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware > sectors (500108 MB) > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write Protect is off > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read > cache: enabled, doesn't support DPO or FUA > > lspci: > 00:00.0 Host bridge: ATI Technologies Inc Unknown device 7910 > 00:01.0 PCI bridge: ATI Technologies Inc Unknown device 7912 > 00:07.0 PCI bridge: ATI Technologies Inc Unknown device 7917 > 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA > 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) > 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) > 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) > 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) > 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) > 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) > 00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 13) > 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE > 00:14.2 Audio device: ATI Technologies Inc SB600 Azalia > 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge > 00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon X1200 Series > 01:05.2 Audio device: ATI Technologies Inc Radeon X1200 Series Audio > Controller > 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) > 03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host > Controller (rev c0) > > thanks and best regards > > zsolt > sorry, kernel version is: 2.6.23-gentoo-r1 -- 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/
ATA bus error with external hd on esata
hi list, i just bought a "MyBook" called external HD with a fixed enclosure, from WD. Connected to the SATA port i constantly get "ATA bus error" messages in the kernel log. Is this a known issue? /var/log/messages: Dec 15 18:37:53 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Dec 15 18:37:53 proto1 ata2.00: irq_stat 0x4001 Dec 15 18:37:53 proto1 ata2.00: cmd 35/00:e0:a7:d2:01/00:01:33:00:00/e0 tag 0 cdb 0x0 data 245760 out Dec 15 18:37:53 proto1 res 51/84:00:86:d4:01/00:00:33:00:00/e0 Emask 0x10 (ATA bus error) Dec 15 18:37:54 proto1 ata2: soft resetting port Dec 15 18:37:54 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 15 18:37:54 proto1 ata2.00: configured for UDMA/33 Dec 15 18:37:54 proto1 ata2: EH complete Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write Protect is off Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 15 18:38:15 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Dec 15 18:38:15 proto1 ata2.00: irq_stat 0x4001 Dec 15 18:38:15 proto1 ata2.00: cmd 35/00:80:bf:09:14/00:01:33:00:00/e0 tag 0 cdb 0x0 data 196608 out Dec 15 18:38:15 proto1 res 51/84:00:3e:0b:14/00:00:33:00:00/e0 Emask 0x10 (ATA bus error) Dec 15 18:38:15 proto1 ata2: soft resetting port Dec 15 18:38:15 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 15 18:38:15 proto1 ata2.00: configured for UDMA/33 Dec 15 18:38:15 proto1 ata2: EH complete Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write Protect is off Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA lspci: 00:00.0 Host bridge: ATI Technologies Inc Unknown device 7910 00:01.0 PCI bridge: ATI Technologies Inc Unknown device 7912 00:07.0 PCI bridge: ATI Technologies Inc Unknown device 7917 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 13) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SB600 Azalia 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon X1200 Series 01:05.2 Audio device: ATI Technologies Inc Radeon X1200 Series Audio Controller 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) 03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0) thanks and best regards zsolt -- 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: Regression: Wireshark sees no packets in 2.6.24-rc3
On Sat, 2007-12-15 at 00:16 -0800, Ray Lee wrote: > On Dec 14, 2007 11:09 PM, Ray Lee <[EMAIL PROTECTED]> wrote: > > On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote: > > Correct, absolutely no traffic. So if it works for you, then either > > it's something that got fixed between -rc3 and -rc5, or something odd > > when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 > > kernel?) Regardless, -rc5 is currently building, and I'll try it in > > the morning. > > -rc5 works great. Really don't know what's different between my -rc3 > and -rc5 builds. I have an -rc3+wireless bits which also works great wrt. tcpdump/wireshark. johannes signature.asc Description: This is a digitally signed message part
Re: Top kernel oopses/warnings this week
Arjan van de Ven wrote: > Stefan Richter wrote: >> Report counts may be too high due to duplicate recognition of the very >> same report. > > this is true however it's .. a hard issue. It's really hard to > distinguish a duplicate report from two reports of the same bug. Would be nice though to try to find duplicates like the example I gave. (The actual report and a reply was listed. The reply just had a full quote of the oops, with "> " prepended and perhaps lines wrapped.) Because if an oops is independently reported twice or more, this too says something about the issue. E.g. flaky RAM and such is pretty much eliminated as a possible cause. Anyway, someone who is actually interested in a particular oops and looks at the posts in your links quickly notices eventual duplicates. But it would be helpful to people who only have a quick glance at the bar graphs if you add a note of caution that the figures are not accurate and not representative, e.g. because of occasional duplicates. For the same reason, please don't write headings like "Oops statistics for kernel 2.6.23-release". Unless you mean "statistics" in a narrower sense like they do statistics in medicine and economics. ;-) Simply write "Oops reports for kernel...". >> Reports against 2.6.X-rcY-mmZ are listed in the same category as reports >> against 2.6.X-rcY. To distinguish -mm reports from vanilla reports, one >> has to look into the details of each bug entry.¹ > > finding what exact kernel version an oops is from is... surprisingly hard. > And to be honest, bugs against -mm are still very interesting, since > they'll be the next mainline after all Yes, they definitely are interesting. And it's the same like with the above issue: People who are genuinely interested in an oops find the necessary information at the details page. Separating them from mainline oopses would be a service though for people who want to - have a quick look at what's urgent and what's not so urgent, - draw conclusions about the state of the release candidates. So this is not that important. -- Stefan Richter -=-=-=== ==-- - http://arcgraph.de/sr/ -- 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.24-rc5-mm1
FWIW, I got the following at reboot after some tests were finished: get_unused_fd: slot 3 not NULL! get_unised_fd: slot 4 not NULL! general protection fault: [1] PREEMPT SMP last sysfs file /sys/class/scsh_host/host1/link_power_management_policy and that's all. -- 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.24-rc5-mm1 compile failure: usbhid_lookup_quirk
MODPOST 196 modules ERROR: "usbhid_lookup_quirk" [drivers/hid/usbhid/usbmouse.ko] undefined! ERROR: "usbhid_lookup_quirk" [drivers/hid/usbhid/usbkbd.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 The problem was fixed by defining CONFIG_USB_HID=m - but I think that should happen automatically if it is necessary. .config was created by running make oldconfig against 2.6.23-rc8-mm2: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Sat Sep 29 07:37:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_NONIRQ_WAKEUP=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_NR_CPUS=2 CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_PENDING_IRQ=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is
Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Sat, 15 Dec 2007, Thomas Gleixner wrote: I have a patch staged for Linus, which fixes a thinko in the broadcast code. It might be related to your problem. Can you give it a try ? Yep - this looks promising. No soft lockups for last half an hour with 4-5 Wakeups from idle. It is almost smooth - jerkiness gone down by 99%. There are still very infrequent and quick spells where the key typed on the keyboard takes effect a little later - but nothing like earlier. I will run it for a little longer just to be sure - but I don't think it will be a problem. Thanks Thomas. Parag -- 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 3/3] [UDP6]: Counter increment on BH mode
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
> >
> > Never mind, we already have that in local_t and as Alexey correctly
> > points out, USER is still going to be the expensive variant with the
> > preempt_disable (well until BH gets threaded). So how about this patch?
>
> I didn't hear any objections so here is the patch again.
>
> [SNMP]: Fix SNMP counters with PREEMPT
>
> The SNMP macros use raw_smp_processor_id() in process context which is
> illegal because the process may be preempted and then migrated to
> another CPU.
nit: please use 'invalid' instead of 'illegal'.
> This patch makes it use get_cpu/put_cpu to disable preemption.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> - (per_cpu_ptr(mib[1], raw_smp_processor_id())->mibs[field]++)
> + do { \
> + per_cpu_ptr(mib[1], get_cpu())->mibs[field]++; \
> + put_cpu(); \
> + } while (0)
> - (per_cpu_ptr(mib[1], raw_smp_processor_id())->mibs[field] += addend)
> + do { \
> + per_cpu_ptr(mib[1], get_cpu())->mibs[field] += addend; \
> + put_cpu(); \
> + } while (0)
we could perhaps introduce stat_smp_processor_id(), which signals that
the CPU id is used for statistical purposes and does not have to be
exact? In any case, your patch looks good too.
Ingo
--
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.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
Andrew Morton wrote, On 12/15/2007 12:13 PM:
> On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
...
>> I applied the patch and then tried my test again. This time my system
>> locked up.
>> Perhaps I should open a new thread for this, since the problem looks
>> pretty different.
>>
>> Dec 14 21:32:55 feargod kernel: process `cat' is using deprecated
>> sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use
>> net.ipv6.neigh.default.retran
>> s_time_ms instead.
>> Dec 14 21:32:55 feargod kernel:
>> Dec 14 21:32:55 feargod kernel: =
>> Dec 14 21:32:55 feargod kernel: [ BUG: bad unlock balance detected! ]
>> Dec 14 21:32:55 feargod kernel: -
>> Dec 14 21:32:55 feargod kernel: cat/6180 is trying to release lock
>> (kkk�H3��) at:
>> Dec 14 21:32:55 feargod kernel: [packet_seq_stop+0xe/0x10]
>> packet_seq_stop+0xe/0x10
>> Dec 14 21:32:55 feargod kernel: but there are no more locks to release!
>> Dec 14 21:32:55 feargod kernel:
>> Dec 14 21:32:55 feargod kernel: other info that might help us debug this:
>> Dec 14 21:32:55 feargod kernel: 2 locks held by cat/6180:
>> Dec 14 21:32:55 feargod kernel: #0: (>lock){--..}, at:
>> [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
>> Dec 14 21:32:55 feargod kernel: #1:
>> (>packet.sklist_lock){-.--}, at: [packet_seq_start+0x14/0x4d]
>> packet_seq_start+0x14/0x4d
Miles, I didn't check this yet, but since there were some considerable
changes, including locking, you could try with reverting some of these
last 3 patches to net/packet by Denis:
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.25.git;a=history;f=net/packet/af_packet.c;h=485af5691d64270a02322925a6ccfad9d02b7f78;hb=HEAD
Regards,
Jarek P.
--
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: Top kernel oopses/warnings this week
Stefan Richter wrote: Arjan van de Ven wrote: The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas; A few comments: Report counts may be too high due to duplicate recognition of the very same report.¹ this is true however it's .. a hard issue. It's really hard to distinguish a duplicate report from two reports of the same bug. Reports against 2.6.X-rcY-mmZ are listed in the same category as reports against 2.6.X-rcY. To distinguish -mm reports from vanilla reports, one has to look into the details of each bug entry.¹ finding what exact kernel version an oops is from is... surprisingly hard. And to be honest, bugs against -mm are still very interesting, since they'll be the next mainline after all A general weakness is that it is ultimately impossible to know whether a report was against an unpatched kernel, unless one drills down to the individual mailinglist threads. for the same reason patched kernels are relevant. And if someone has a super weirdo kernel, well, as long as we get enough bug data it'll be way down in the noise. Reports about tainted kernels have arguably less value. It would be good to hide such reports until a report of the same oops in an untainted kernel was found. That's half of what is done right now; they're not hidden though, just very clearly marked. -- 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 00/60] 2.6.23-stable review
On Sat, Dec 15, 2007 at 05:09:48PM +0100, Jan Evert van Grootheest wrote: > Greg KH wrote: >> This is the start of the stable review cycle for the 2.6.23.10 release. >> There are 60 patches in this series, all will be posted as a response to >> this one. If anyone has any issues with these being applied, please let >> us know. If anyone is a maintainer of the proper subsystem, and wants >> to add a Signed-off-by: line to the patch, please respond with it. >> >> > Hi Greg, > > Do you think it might be possible to add the subjects of the patches > next time in the announcement? This would give people an easy way > (besides the diffstat) to check what is getting fixed. The subject of the individual patches are in the email thread that is attached to this announcement, so it should be quite simple to get this information by just looking in your mail reader :) Also, it would be hard to do this, unless someone has a patch to quilt to provide this kind of information? 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: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 02:34:42PM +0800, Herbert Xu wrote: > On Sat, Dec 15, 2007 at 05:31:30PM +1100, Benjamin Herrenschmidt wrote: > > > > That's something I've actually never quite liked... the fact that we > > evaluate the expression anyway. I'm pretty happy with -not- evaluating > > the expression when CONFIG_BUG is on most of the time since whatever is > > in there is purely here for the sake of the BUG/WARN test. > > Whether we evaluate the expression is a completely different debate. > I personally agree with you that expressions that have side-effects > are a stupid idea for either WARN_ON or BUG_ON. As do I. But we can't really do anything about it short of auditing them all. -- Mathematics is the supreme nostalgia of our time. -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> a minor concern, but I did also point out that using an unused port > causes the bus to be tied up for a microsecond or two, which matters on > a fast SMP machine. And I did point out I'd found locking cases that may be relying upon this > I also note that curent machines like the problem machine have ACPI, and > maybe those would be the ones that vendors might start to define port 80 > to mean something. As I noted, it /seems/ to be only when ACPI is turned Port 0x80 means debug. You appear to have a laptop with some kind of buggy firmware that wants a BIOS update. Everyone use 0x80 for debug - its in the chipset hardware quite often. > My belief is that my machine has some device that is responding to port > 80 by doing something. And that something requires some other program > to "service" port 80 in some way. But it sure would be nice to know. > I can't personally sand off the top of the chipset to put probes into it > - so my normal approach of putting a logic analyzer on the bus doesn't work. Almost certainly a SMI trap. > PS: If I have time, I may try to build Rene's port 80 test for Windows > and run it under WinXP on this machine That would be very interesting. Alan -- 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] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
On Sat, Dec 15, 2007 at 02:52:11PM +0800, Herbert Xu wrote: > On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote: > > > > I suppose we'll have to either introduce a new primitive or just > > go back to using BUG_ON. > > Let's do the conservative thing and add a new primitive. > > [PATCH] Added BARF_ON/BARF_ON_ONCE > > The description of CONFIG_BUG clearly states that both BUG and > WARN_ON may be skipped. However, our actual implementation still > checks the condition on WARN_ON if it's used as part of an if > statement or such. > > I tried to compile it away but Matt Mackall pointed out that > people may already be using it in ways that were not intended. > In particular, it may have been used for conditions that are > thought to be possible. > > So this patch adds a new pair of macros BARF_ON and BARF_ON_ONCE > that are clearly marked as such to prevent abuse. The intended > usage model is identical to WARN_ON except that they should only > be used for conditions that are thought to be impossible. In > other words, only use them to replace BUG_ON's that may be called > by an IRQ handler or within locks. Egads, this just makes the whole bad BUG_ON vs WARN_ON situation worse. This adds yet another non-distinction, because the difference between BUG_ON and WARN_ON has absolutely nothing to do with the (perceived or actual) probability of the condition. We've got plenty of evidence that BUG_ON and WARN_ON conditions -do- happen. So choosing between BUG_ON and WARN_ON is choosing whether a box should be forcibly killed or not and nothing more. You've clearly got a use-case in mind where WARN_ON + !CONFIG_BUG isn't doing what you want, please share it with us. -- Mathematics is the supreme nostalgia of our time. -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
> My understanding is that the linux starts in real mode, and uses the > BIOS for such things as reading the very first image. Not always. We may enter from 32bit in some cases, and we may also not have a PC BIOS in the first place. -- 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.24-rc5-mm1: kernel BUG at include/linux/scatterlist.h:59!
John> Just fired up 2.6.24-rc5-mm1 on a Dual CPU PIII 550mhz system John> with 2gb of RAM. Got the following error. Let me know if you John> need more details or want me to run tests or make changes. John> Looks like something in the SCSI st driver, which makes sense John> since I have a pair of DLT 7k drives hooked upto this system via John> a Symbios PCI card. I've also got a P1000 jukebox on there as John> well. John> [ 354.338667] kernel BUG at include/linux/scatterlist.h:59! John> [ 354.403311] invalid opcode: [#1] SMP John> [ 354.452774] last sysfs file: John> /sys/devices/pci:00/:00:0d.1/host3/target3:0:3/3:0:3:0/vendor John> [ 354.560099] Modules linked in: John> [ 354.596859] John> [ 354.614753] Pid: 1795, comm: stinit Not tainted (2.6.24-rc5-mm1 #3) John> [ 354.689825] EIP: 0060:[] EFLAGS: 00010213 CPU: 0 John> [ 354.755538] EIP is at st_do_scsi+0x2e0/0x340 John> [ 354.806668] EAX: EBX: ECX: c16e1f80 EDX: f7f87050 John> [ 354.881731] ESI: f7f877d0 EDI: 1000 EBP: f7f87000 ESP: f7167db0 John> [ 354.956788] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 John> [ 355.021452] Process stinit (pid: 1795, ti=f7167000 task=f74d7030 John> task.ti=f7167000) John> [ 355.110028] Stack: 0003 f7f87050 00d59f80 John> f75cf9e0 c0359840 John> [ 355.211879]00d0 f7167e54 f7d2bc00 f75cf9e0 f7d2bc18 John> 0006 f7167e54 John> [ 355.313757]f7d2bc00 f7167e64 f7f87000 c0358730 0006 John> 0002 000dbba0 John> [ 355.415639] Call Trace: John> [ 355.447258] [] st_sleep_done+0x0/0x70 John> [ 355.502773] [] check_tape+0x510/0x640 John> [ 355.558284] [] st_open+0x18b/0x220 John> [ 355.610677] [] exact_match+0x0/0x10 John> [ 355.664113] [] st_open+0x0/0x220 John> [ 355.714429] [] chrdev_open+0x9f/0x190 John> [ 355.769945] [] chrdev_open+0x0/0x190 John> [ 355.824418] [] __dentry_open+0xb5/0x2a0 John> [ 355.882013] [] permission+0xdb/0x100 John> [ 355.936486] [] nameidata_to_filp+0x47/0x60 John> [ 355.997200] [] open_pathname+0x17d/0x740 John> [ 356.055831] [] update_curr+0x80/0x110 John> [ 356.111345] [] scheduler_tick+0xe2/0x130 John> [ 356.169979] [] getname+0xa5/0xc0 John> [ 356.220294] [] do_sys_open+0x4c/0xe0 John> [ 356.274770] [] sys_open+0x1c/0x20 John> [ 356.326123] [] syscall_call+0x7/0xb John> [ 356.379559] === John> [ 356.422393] Code: 32 8b 54 24 28 89 44 24 2c 89 50 74 e9 ba fd ff ff 0f 0b eb fe 8d b6 00 00 00 00 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d 74 26 00 <0f> 0b eb fe 0f 0b eb fe 64 a1 00 50 6e c0 8b 40 04 8b 40 08 a8 John> [ 356.661693] EIP: [] st_do_scsi+0x2e0/0x340 SS:ESP John> 0068:f7167db0 Just to add some additional information, when I use Bacula to load a new tape into a drive (using mtx really) I get yet another BUG on all my screens: jfsnew kernel: [60861.268812] [ cut here ] jfsnew kernel: [60861.388789] invalid opcode: [#2] SMP jfsnew kernel: [60861.438055] last sysfs file: /sys/devices/pci:00/:00:13.0/:03:0e.0/local_cpus jfsnew kernel: [60862.019200] Process mt (pid: 8860, ti=c6967000 task=c6908570 task.ti=c6967000) jfsnew kernel: [60862.103613] Stack: 0003 f745e050 00d59f80 f135bd60 c0359840 jfsnew kernel: [60862.204859]00d0 c6967e54 f7d2b600 f135bd60 f7d2b618 0006 c6967e54 jfsnew kernel: [60862.305804]f7d2b600 c6967e64 f745e000 c0358730 0006 0002 000dbba0 jfsnew kernel: [60862.406746] Call Trace: jfsnew kernel: [60862.438156] [] st_sleep_done+0x0/0x70 jfsnew kernel: [60862.493665] [] check_tape+0x510/0x640 jfsnew kernel: [60862.549179] [] st_open+0x18b/0x220 jfsnew kernel: [60862.601572] [] st_open+0x0/0x220 jfsnew kernel: [60862.651886] [] chrdev_open+0x9f/0x190 jfsnew kernel: [60862.707402] [] chrdev_open+0x0/0x190 jfsnew kernel: [60862.761876] [] __dentry_open+0xb5/0x2a0 jfsnew kernel: [60862.819469] [] permission+0xdb/0x100 jfsnew kernel: [60862.873946] [] nameidata_to_filp+0x47/0x60 jfsnew kernel: [60862.934659] [] open_pathname+0x17d/0x740 jfsnew kernel: [60862.993292] [] handle_mm_fault+0xff/0x580 jfsnew kernel: [60863.052966] [] getname+0xa5/0xc0 jfsnew kernel: [60863.103277] [] do_sys_open+0x4c/0xe0 jfsnew kernel: [60863.157752] [] sys_open+0x1c/0x20 jfsnew kernel: [60863.209110] [] syscall_call+0x7/0xb jfsnew kernel: [60863.262544] [] sunrpc_cache_update+0x140/0x180 jfsnew kernel: [60863.327413] === jfsnew kernel: [60863.370246] Code: 32 8b 54 24 28 89 44 24 2c 89 50 74 e9 ba fd ff ff 0f 0b eb fe 8d b6 00 00 00 00 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d 74 26 00 <0f> 0b eb fe 0f 0b eb fe 64 a1 00 50 6e c0 8b 40 04 8b 40 08 a8 jfsnew kernel: [60863.602895] EIP: [] st_do_scsi+0x2e0/0x340 SS:ESP 0068:c6967db0 I wonder if
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
H. Peter Anvin wrote: David P. Reed wrote: Just a thought for a way to fix the "very early" timing needed to set up udelay to work in a way that works on all machines. Perhaps we haven't exploited the BIOS enough: The PC BIOS since the PC AT (286) has always had a standard "countdown timer" way to delay for n microseconds, which as far as I know still works. This can be used to measure the speed of a delay loop, without using ANY in/out instructions directly (the ones in the BIOS are presumably correctly delayed...). If we enter from the 32-bit entrypoint, we already don't have access to the BIOS, though. My understanding is that the linux starts in real mode, and uses the BIOS for such things as reading the very first image. arch/x86/boot/main.c seems to use BIOS calls, and one can do what I wrote in C or asm. Good place to measure the appropriate delay timing, and pass it on forward. That's what I was suggesting, which is why I copied the ASM routine from my old code listing as I did. -- 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/
Update on collectl
Last summer I announced that I had released a performance monitoring tool called collectl and just wanted to let people know I've since significantly improved the website at http://collectl.sourceforge.net/ to include examples, a block diagram and even included a couple of pages on some interesting kernel problems it helped identify, though they've since been addressed. Perhaps one of the more interesting ones is that not too long ago, and I'm really not sure when it actually got fixed, it was impossible to accurately measure network traffic at 1 second intervals and worse, you'd periodically see double the actual rate reported. Try it out on an older kernel and see for yourself! However, since collectl can monitor at subsecond intervals you could monitor those older kernels at 0.9765 seconds and see accurate data. Rather than me try to explain it, take a look at http://collectl.sourceforge.net/NetworkStats.html to read more. I think a couple of other features I may not have said enough about is monitoring Infiniband and Lustre performance, for which I don't believe there are any good tools available. You can get IB data from asking the switch, but you can't easily get it from the local system. There is actually a wealth of information Lustre provides but no good tools to mine it. Now there is. With collectl you can see a second-by-second (or any other interval you prefer) snapshot of just what is happening to these key resources and can even watch the load on cpu, memory and network at the same time. If you prefer, and most people do, just run collectl as a service and it will maintain a set of compressed rolling logs containing 10 second samples (all customizable) and do it all at <0.1% of system overhead. Enough rambling already. Download it and see for yourselves... -mark -- 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 3/3] [UDP6]: Counter increment on BH mode
Herbert Xu a écrit :
Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
Never mind, we already have that in local_t and as Alexey correctly
points out, USER is still going to be the expensive variant with the
preempt_disable (well until BH gets threaded). So how about this patch?
I didn't hear any objections so here is the patch again.
[SNMP]: Fix SNMP counters with PREEMPT
The SNMP macros use raw_smp_processor_id() in process context
which is illegal because the process may be preempted and then
migrated to another CPU.
This patch makes it use get_cpu/put_cpu to disable preemption.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
#define SNMP_INC_STATS_USER(mib, field) \
- (per_cpu_ptr(mib[1], raw_smp_processor_id())->mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())->mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_INC_STATS(mib, field) \
(per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())->mibs[field]++)
How come you change SNMP_INC_STATS_USER() but not SNMP_INC_STATS() ?
--
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.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
Andrew Morton wrote, On 12/15/2007 12:13 PM: > On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote: > >> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: >>> On Fri, 14 Dec 2007 17:13:21 -0500 >>> "Miles Lane" <[EMAIL PROTECTED]> wrote: ... Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26) ... note: cat[6944] exited with preempt_count 4 ... >> Dec 14 21:32:55 feargod kernel: cat/6180 is trying to release lock ... > Can you suggest a way in which others can reproduce this? Buy a cat? Jarek P. -- 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 007 of 7] md: Get name for block device in sysfs
On Dec 14, 2007 7:26 AM, NeilBrown <[EMAIL PROTECTED]> wrote:
>
> Given an fd on a block device, returns a string like
>
> /block/sda/sda1
>
> which can be used to find related information in /sys.
>
> Ideally we should have an ioctl that works on char devices as well,
> but that seems far from trivial, so it seems reasonable to have
> this until the later can be implemented.
>
> Cc: Jens Axboe <[EMAIL PROTECTED]>
> Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
>
> ### Diffstat output
> ./block/ioctl.c | 13 +
> ./include/linux/fs.h |2 ++
> 2 files changed, 15 insertions(+)
>
> diff .prev/block/ioctl.c ./block/ioctl.c
> --- .prev/block/ioctl.c 2007-12-14 17:18:50.0 +1100
> +++ ./block/ioctl.c 2007-12-14 16:15:41.0 +1100
> @@ -227,8 +227,21 @@ int blkdev_ioctl(struct inode *inode, st
> struct block_device *bdev = inode->i_bdev;
> struct gendisk *disk = bdev->bd_disk;
> int ret, n;
> + char b[BDEVNAME_SIZE*2 + 10];
>
> switch(cmd) {
> + case BLKGETNAME:
> + strcpy(b, "/block/");
As pointed out to when you came up with the idea, we can't do this. A devpath
is a path to the device and will not necessarily start with "/block" for block
devices. It may start with "/devices" and can be much longer than
BDEVNAME_SIZE*2 + 10.
Please do not apply!
Kay
--
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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
This change seems rather unlikely for 2.6.24 at this point (high risk), but could be good for 2.6.25. One thing it should probably have for the early going, is a simple way to turn it on/off at boot time, so that we don't have people "stuck" unable to run the test kernels should something weird happen. Alan / David / Ingo, What do you think of the idea of a *temporary* boot flag for this, something like port80=on/off (pick a suitable name) ? Cheers -- 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: /dev/urandom uses uninit bytes, leaks user data
On Sat, Dec 15, 2007 at 03:13:19PM +0800, Herbert Xu wrote: > John Reiser <[EMAIL PROTECTED]> wrote: > > > > If speed matters that much, then please recoup 33 cycles on x86 > > by using shifts instead of three divides, such as (gcc 4.1.2): > > > >add_entropy_words(r, tmp, (bytes + 3) / 4); > > > > 0x8140689 :lea0x3(%esi),%eax > > 0x814068c :mov$0x4,%dl > > 0x814068e :mov%edx,%edi > > 0x8140690 :cltd > > 0x8140691 :idiv %edi > > There ought to be a warning about this sort of thing. Indeed. Seems it would be better to adjust the types appropriately. Anyway, this is no longer relevant to [EMAIL PROTECTED] -- Mathematics is the supreme nostalgia of our time. -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
I understand the risks of such a fundamental change, and it may be only a minor concern, but I did also point out that using an unused port causes the bus to be tied up for a microsecond or two, which matters on a fast SMP machine. Of course all the other concerns you guys are worrying about are really important. I don't want to break anybody's running systems... I'd like to see my machine run smoothly, and all the other machines that may or may not have this problem (google "hwclock freeze" to see that I'm far from alone - I just have persevered in "bisecting" this problem with kernel tweaks for months, whereas the others did not or did not know how). By the way, this laptop is really nice for Linux in lots of ways. Dual drives, so I set it up with software RAID for reliability, dual 64-bit processors, fast 3D graphics, etc. Great battery life. Just one last kernel issue. I also note that curent machines like the problem machine have ACPI, and maybe those would be the ones that vendors might start to define port 80 to mean something. As I noted, it /seems/ to be only when ACPI is turned on that this problem happens on my machine - that's when the OS starts to be involved in servicing various things, so it suggests that maybe things change about port 80's unknown function on these machines when ACPI is servicing the system management code (that's not something I have been able to verify). My belief is that my machine has some device that is responding to port 80 by doing something. And that something requires some other program to "service" port 80 in some way. But it sure would be nice to know. I can't personally sand off the top of the chipset to put probes into it - so my normal approach of putting a logic analyzer on the bus doesn't work. PS: If I have time, I may try to build Rene's port 80 test for Windows and run it under WinXP on this machine (I still have a crappy little partition that boots it). If it freezes the same way, it's almost certain a design "feature", and if it doesn't freeze, we might suspect that there is compensating logic in either Windows ACPI code or some way that windows "sets up" the machine. Alan Cox wrote: On Sat, 15 Dec 2007 14:27:25 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: The issue is -- how do you safely replace the outb pre-loops_per_jiffy calibration? I'm currently running with the attached hack (not submitted, only for 32-bit and discussion) the idea of which might be the best we can do? how about doing a known-NOP chipset cycle? For example: inb(PIC_SLAVE_IMR) It needs tobe a different chip to the main one (or macrocell anyway) - so PIC for PIT and vice versa. However since we know 0x80 works for everything on the planet but this one specifies of laptop which seems to need a firmware update its a very high risk approach. Alan -- 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 00/60] 2.6.23-stable review
Greg KH wrote: This is the start of the stable review cycle for the 2.6.23.10 release. There are 60 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. Hi Greg, Do you think it might be possible to add the subjects of the patches next time in the announcement? This would give people an easy way (besides the diffstat) to check what is getting fixed. Thanks, Jan Evert -- 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: [perfmon2] perfmon2 merge news
Stephane Eranian <[EMAIL PROTECTED]> writes: > [...] >> > [...] AFAIK, there is no single call to stop T1 and wait until it >> > is completely off the CPU, unless we go through the (internal) >> > ptrace interface. >> >> The utrace code supports this style of thread manipulation better >> than ptrace. > > Afre you saying that utrace provides a utrace_thread_stop(tid) call > that returns only when the thread tid is off the CPU. And then there > is a utrace_thread_resume(tid) call. If that's the case then that is > what I need. While I see no single call, it can be synthesized from a sequence of them: utrace_attach, utrace_set_flags (... UTRACE_ACTION_QUESCE ...), then waiting for a callback. Roland, is there a more compact way? > How are we with regards to utrace integration? Roland McGrath is working on breaking the patches down. - FChE -- 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: Top kernel oopses/warnings this week
Arjan van de Ven wrote: > The http://www.kerneloops.org website collects kernel oops and warning > reports from various mailing lists and bugzillas; A few comments: Report counts may be too high due to duplicate recognition of the very same report.¹ Reports against 2.6.X-rcY-mmZ are listed in the same category as reports against 2.6.X-rcY. To distinguish -mm reports from vanilla reports, one has to look into the details of each bug entry.¹ A general weakness is that it is ultimately impossible to know whether a report was against an unpatched kernel, unless one drills down to the individual mailinglist threads. Reports about tainted kernels have arguably less value. It would be good to hide such reports until a report of the same oops in an untainted kernel was found. ¹) example: http://www.kerneloops.org/oops.php?number=2335 -- Stefan Richter -=-=-=== ==-- - http://arcgraph.de/sr/ -- 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: kobject ->k_name memory leak
On Sat, 2007-12-15 at 16:34 +0300, Alexey Dobriyan wrote: > On Fri, Dec 14, 2007 at 01:48:23PM -0800, Greg KH wrote: > > On Mon, Dec 03, 2007 at 01:25:51PM -0800, Greg KH wrote: > > > On Tue, Dec 04, 2007 at 12:09:59AM +0300, Alexey Dobriyan wrote: > > > > On Mon, Dec 03, 2007 at 12:47:16PM -0800, Greg KH wrote: > > > > > On Mon, Dec 03, 2007 at 12:26:07PM +0300, Alexey Dobriyan wrote: > > > > > > Hi, Greg! > > > > > > > > > > > > Commit ce2c9cb0259acd2aed184499ebe41ab00da13b25 aka > > > > > > "kobject: remove the static array for the name" introduced memory > > > > > > leak > > > > > > of a module name after modprobe/rmmod. Apparently for modules > > > > > > ->release > > > > > > callback is NULL. > > > > > > > > > > > > kobject_cleanup: ->release = , name = 'foo_sysctl' > > > > > > Pid: 1927, comm: rmmod Not tainted > > > > > > 2.6.24-rc3-e1cca7e8d484390169777b423a7fe46c7021fec1 #5 > > > > > > [] kobject_cleanup+0xb8/0xc0 > > > > > > [] kobject_release+0x0/0x10 > > > > > > [] kref_put+0x2b/0xa0 > > > > > > [] _spin_unlock+0x25/0x40 > > > > > > [] free_module+0x78/0xd0 > > > > > > [] sys_delete_module+0x12f/0x1a0 > > > > > > > > > > Hm, _which_ kobject associated with a module, there are 3 of them I > > > > > think :) > > > > > > > > Ouch! > > > > > > > > > They should all have a release function, and if they do not, we think > > > > > it's a "static" kobject and it is not safe to free that name. > > > > > > > > > > I've been working on cleaning this up a lot in the -mm tree with over > > > > > 80 > > > > > patches for the kset/kobject apis and interfaces. > > > > > > > > > > But if we have a dynamic kobject, and we aren't freeing it properly, > > > > > please let me know which one it is and I'll work to fix it for 2.6.24. > > > > > > > > The one which is passed to kobject_set_name() in mod_sysfs_init().. > > > > > > That one should be set to the module_ktype, which is in kernel/params.c, > > > so the release function there should... oh crap, there is no release > > > function. That's a bug. After I get out of meetings tonight I'll write > > > up a patch for that, unless someone beats me to it :) > > > > Ok, this is a mess. We can't really have a release function for this > > kobject, as the structure it is embedded it has it's own memory > > management issues. > > > > To fix this properly is going to take some major kobject/module surgery, > > it's not a simple fix at all. I'll tackle it for 2.6.25, as it fits in > > nicely with the other kobject rework that I've already done in the -mm > > tree. > > > > So, for now, can we just live with this tiny memory leak on module > > unload? > > For the record, this leak screws any testing one can do wrt module > unload races. You can't really leave box overnight running > modprobe/rmmod in a loop, because OOM killer will finally kick in. > Hey, this is exactly how it was noticed at all. > > > Or is the above trace something that users will see when unloading > > modules? > > No, it's added debugging. Can't we add an empty release function? It would free the name with the current logic, right? Kay -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Sat, 15 Dec 2007 14:27:25 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Rene Herman <[EMAIL PROTECTED]> wrote: > > > The issue is -- how do you safely replace the outb pre-loops_per_jiffy > > calibration? I'm currently running with the attached hack (not > > submitted, only for 32-bit and discussion) the idea of which might be > > the best we can do? > > how about doing a known-NOP chipset cycle? For example: > > inb(PIC_SLAVE_IMR) It needs tobe a different chip to the main one (or macrocell anyway) - so PIC for PIT and vice versa. However since we know 0x80 works for everything on the planet but this one specifies of laptop which seems to need a firmware update its a very high risk approach. Alan -- 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.24-rc5] sym53c8xx_2 modpost section mismatch fix
Building 2.6.24-rc5 with
# CONFIG_HOTPLUG is not set
CONFIG_SCSI_SYM53C8XX_2=y
results in
WARNING: vmlinux.o(.text+0x14b36c): Section mismatch: reference to
.exit.text:sym2_remove (between 'sym2_io_error_detected' and
'sym_set_cam_result_error')
because sym2_io_error_detected() calls sym2_remove(), which is marked __devexit.
Fixed by removing the __devexit from sym2_remove().
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
--- linux-2.6.24-rc5/drivers/scsi/sym53c8xx_2/sym_glue.c.~1~2007-12-15
15:37:04.0 +0100
+++ linux-2.6.24-rc5/drivers/scsi/sym53c8xx_2/sym_glue.c2007-12-15
16:22:08.0 +0100
@@ -1744,7 +1744,7 @@ static int __devinit sym2_probe(struct p
return -ENODEV;
}
-static void __devexit sym2_remove(struct pci_dev *pdev)
+static void sym2_remove(struct pci_dev *pdev)
{
struct Scsi_Host *shost = pci_get_drvdata(pdev);
@@ -2056,7 +2056,7 @@ static struct pci_driver sym2_driver = {
.name = NAME53C8XX,
.id_table = sym2_id_table,
.probe = sym2_probe,
- .remove = __devexit_p(sym2_remove),
+ .remove = sym2_remove,
.err_handler= _err_handler,
};
--
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/
