Re: kernel BUG at ide-cd.c:1726 in 2.6.24-03863-g0ba6c33 && -g8561b089

2008-01-31 Thread Florian Lohoff
On Thu, Jan 31, 2008 at 02:05:58PM +0100, Jens Axboe wrote:
> The below fix should be enough. It's perfectly legal to have leftover
> byte counts when the drive signals completion, happens all the time for
> eg user issued commands where you don't know an exact byte count.
> 
> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 74c6087..bee05a3 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1722,7 +1722,7 @@ static ide_startstop_t cdrom_newpc_intr(ide_drive_t 
> *drive)
>*/
>   if ((stat & DRQ_STAT) == 0) {
>   spin_lock_irqsave(_lock, flags);
> - if (__blk_end_request(rq, 0, 0))
> + if (__blk_end_request(rq, 0, rq->data_len))
>   BUG();
>   HWGROUP(drive)->rq = NULL;
>   spin_unlock_irqrestore(_lock, flags);
> 

Fixes the crash on boot for me ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: kernel BUG at ide-cd.c:1726 in 2.6.24-03863-g0ba6c33 -g8561b089

2008-01-31 Thread Florian Lohoff
On Thu, Jan 31, 2008 at 02:05:58PM +0100, Jens Axboe wrote:
 The below fix should be enough. It's perfectly legal to have leftover
 byte counts when the drive signals completion, happens all the time for
 eg user issued commands where you don't know an exact byte count.
 
 diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
 index 74c6087..bee05a3 100644
 --- a/drivers/ide/ide-cd.c
 +++ b/drivers/ide/ide-cd.c
 @@ -1722,7 +1722,7 @@ static ide_startstop_t cdrom_newpc_intr(ide_drive_t 
 *drive)
*/
   if ((stat  DRQ_STAT) == 0) {
   spin_lock_irqsave(ide_lock, flags);
 - if (__blk_end_request(rq, 0, 0))
 + if (__blk_end_request(rq, 0, rq-data_len))
   BUG();
   HWGROUP(drive)-rq = NULL;
   spin_unlock_irqrestore(ide_lock, flags);
 

Fixes the crash on boot for me ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: [2.6.24] bcm203x bluetooth dongle does not work

2008-01-30 Thread Florian Lohoff

Hi,

On Wed, Jan 30, 2008 at 06:33:52PM +0100, Marcel Holtmann wrote:
> we moved away from using a timer and using a workqueue now. It wrote the
> patch to use a workqueue and tested that it works. Starting with 2.6.19
> we the usage of a workqueue is default. Can you verify that non of the
> kernels 2.6.19-2.6.23 are working. We might have missed a change inside
> the USB subsystem within the 2.6.24 timeframe.

I went through the kernels i still have on this box (FSC LifeBook E8110) 
and here are the results. Except the debian 2.6.18-5-686 no newer kernel 
works. The onboard bluetooth works like a charm always whereas the
bcm203x simply does not reconnect after loading firmware from 2.6.19 on.

2.6.18-5-686 (debian)   works
2.6.19  breaks
2.6.21-rc5  breaks
2.6.22-rc5  breaks
2.6.22-2-686 (debian)   breaks
2.6.23-1-686 (debian)   breaks
2.6.24  breaks

It basically looks always like this:


usb 1-1: new full speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
Bluetooth: Broadcom Blutonium firmware driver ver 1.1
usbcore: registered new interface driver bcm203x

bcm203x_complete: URB failed with status -84
usb 1-1: USB disconnect, address 2

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: [2.6.24] bcm203x bluetooth dongle does not work

2008-01-30 Thread Florian Lohoff
On Wed, Jan 30, 2008 at 06:33:52PM +0100, Marcel Holtmann wrote:
> we moved away from using a timer and using a workqueue now. It wrote the
> patch to use a workqueue and tested that it works. Starting with 2.6.19
> we the usage of a workqueue is default. Can you verify that non of the
> kernels 2.6.19-2.6.23 are working. We might have missed a change inside
> the USB subsystem within the 2.6.24 timeframe.

My tests were on 2.6.24 which does not work as described. Newer
kernels dont boot due to crash in ide-cd so i cant test ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


[2.6.24] bcm203x bluetooth dongle does not work

2008-01-30 Thread Florian Lohoff

Hi,

after trying around with my ancient bcm2033 bluetooth dongle i found it
not working in 2.6.24 - I debugged udev and found it loading the
firmware correctly but the device seems to have problems disconnecting.

I found an Ubuntu bug which mentions a patch which supposed to be
2.6.20 material. It still applies and fixes my problem:

Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85247

Patch:
http://launchpadlibrarian.net/7058766/bcm203x-2.6.20-backport.diff

So it seems this patch never went in but most likely should.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


[2.6.24] bcm203x bluetooth dongle does not work

2008-01-30 Thread Florian Lohoff

Hi,

after trying around with my ancient bcm2033 bluetooth dongle i found it
not working in 2.6.24 - I debugged udev and found it loading the
firmware correctly but the device seems to have problems disconnecting.

I found an Ubuntu bug which mentions a patch which supposed to be
2.6.20 material. It still applies and fixes my problem:

Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85247

Patch:
http://launchpadlibrarian.net/7058766/bcm203x-2.6.20-backport.diff

So it seems this patch never went in but most likely should.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: [2.6.24] bcm203x bluetooth dongle does not work

2008-01-30 Thread Florian Lohoff

Hi,

On Wed, Jan 30, 2008 at 06:33:52PM +0100, Marcel Holtmann wrote:
 we moved away from using a timer and using a workqueue now. It wrote the
 patch to use a workqueue and tested that it works. Starting with 2.6.19
 we the usage of a workqueue is default. Can you verify that non of the
 kernels 2.6.19-2.6.23 are working. We might have missed a change inside
 the USB subsystem within the 2.6.24 timeframe.

I went through the kernels i still have on this box (FSC LifeBook E8110) 
and here are the results. Except the debian 2.6.18-5-686 no newer kernel 
works. The onboard bluetooth works like a charm always whereas the
bcm203x simply does not reconnect after loading firmware from 2.6.19 on.

2.6.18-5-686 (debian)   works
2.6.19  breaks
2.6.21-rc5  breaks
2.6.22-rc5  breaks
2.6.22-2-686 (debian)   breaks
2.6.23-1-686 (debian)   breaks
2.6.24  breaks

It basically looks always like this:

insert
usb 1-1: new full speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
Bluetooth: Broadcom Blutonium firmware driver ver 1.1
usbcore: registered new interface driver bcm203x
wait for 30 seconds - then pull
bcm203x_complete: URB failed with status -84
usb 1-1: USB disconnect, address 2

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: kernel BUG at ide-cd.c:1726 in 2.6.24-03863-g0ba6c33 && -g8561b089

2008-01-29 Thread Florian Lohoff
On Tue, Jan 29, 2008 at 10:01:45PM +0800, Nai Xia wrote:
> 
> Build environment: debian sid, gcc-4.2.3, i386.
> 
> The bug is in lately git-pull from 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> And it can be reproduced very easily on a machine with normal cdroms.
> It halts booting and I grabbed the bug output with an serial console.

I get this on boot on an Core Duo Lifebook E8110 with an DVD Recorder which
renders this kernel unusable:

[   40.406743] [ cut here ]
[   40.410255] kernel BUG at drivers/ide/ide-cd.c:1726!
[   40.410255] invalid opcode:  [#1] PREEMPT SMP 
[   40.410255] Modules linked in: ehci_hcd(+) ohci1394(+) uhci_hcd(+) output 
yenta_socket(+) rsrc_nonstatic irda parport_pc(+) parport mmc_core ieee1394 
pcmcia_core sky2 ide_cd usbcore crc_ccitt
[   40.410255] 
[   40.410255] Pid: 1115, comm: modprobe Not tainted (2.6.25-rc0 #1)
[   40.410255] EIP: 0060:[] EFLAGS: 00010002 CPU: 0
[   40.410255] EIP is at cdrom_newpc_intr+0xfb/0x29f [ide_cd]
[   40.410255] EAX: 0001 EBX: 0002 ECX: 009e EDX: 0001
[   40.410255] ESI: 0003 EDI: c0547f18 EBP: de52bdbc ESP: de52bd8c
[   40.410255]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   40.410255] Process modprobe (pid: 1115, ti=de52a000 task=de616000 
task.ti=de52a000)
[   40.410255] Stack: c0528d00 de52bda8 df2d9600 de52bdb0 df24bc20  
009e de52bdbc 
[   40.410255]0050 c0547ec0 c0547f18 df24bc00 de52bdf4 c025bc76 
0c64 de54ab7c 
[   40.410255]c050b760 000200d2 c0491758 000e 0202 e0055d75 
de616000 df24d660 
[   40.410255] Call Trace:
[   40.410255]  [] show_trace_log_lvl+0x1a/0x2f
[   40.410255]  [] show_stack_log_lvl+0x9b/0xa3
[   40.410255]  [] show_registers+0xa4/0x1ba
[   40.410255]  [] die+0x11d/0x1fe
[   40.410255]  [] do_trap+0x8a/0xa3
[   40.410255]  [] do_invalid_op+0x88/0x92
[   40.410255]  [] error_code+0x72/0x78
[   40.410255]  [] ide_intr+0x166/0x1c9
[   40.410255]  [] handle_IRQ_event+0x21/0x48
[   40.410255]  [] handle_edge_irq+0xa8/0x10d
[   40.410255]  [] do_IRQ+0x5c/0x78
[   40.410255]  [] common_interrupt+0x23/0x28
[   40.410255]  [] sys_init_module+0x29d/0x18e1
[   40.410255]  [] sysenter_past_esp+0x5f/0x85
[   40.410255]  ===
[   40.410255] Code: f6 45 f0 08 8b 92 98 00 00 00 89 55 e8 75 3e b8 80 e5 4c 
c0 e8 81 6d 32 e0 31 c9 31 d2 89 c3 8b 45 d8 e8 bf 1e 17 e0 85 c0 74 04 <0f> 0b 
eb fe 8b 47 2c 89 da 8b 40 08 c7 40 1c 00 00 00 00 b8 80 
[   40.410255] EIP: [] cdrom_newpc_intr+0xfb/0x29f [ide_cd] SS:ESP 
0068:de52bd8c
[   40.410255] Kernel panic - not syncing: Fatal exception in interrupt

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: kernel BUG at ide-cd.c:1726 in 2.6.24-03863-g0ba6c33 -g8561b089

2008-01-29 Thread Florian Lohoff
On Tue, Jan 29, 2008 at 10:01:45PM +0800, Nai Xia wrote:
 
 Build environment: debian sid, gcc-4.2.3, i386.
 
 The bug is in lately git-pull from 
 
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 
 And it can be reproduced very easily on a machine with normal cdroms.
 It halts booting and I grabbed the bug output with an serial console.

I get this on boot on an Core Duo Lifebook E8110 with an DVD Recorder which
renders this kernel unusable:

[   40.406743] [ cut here ]
[   40.410255] kernel BUG at drivers/ide/ide-cd.c:1726!
[   40.410255] invalid opcode:  [#1] PREEMPT SMP 
[   40.410255] Modules linked in: ehci_hcd(+) ohci1394(+) uhci_hcd(+) output 
yenta_socket(+) rsrc_nonstatic irda parport_pc(+) parport mmc_core ieee1394 
pcmcia_core sky2 ide_cd usbcore crc_ccitt
[   40.410255] 
[   40.410255] Pid: 1115, comm: modprobe Not tainted (2.6.25-rc0 #1)
[   40.410255] EIP: 0060:[e0055e70] EFLAGS: 00010002 CPU: 0
[   40.410255] EIP is at cdrom_newpc_intr+0xfb/0x29f [ide_cd]
[   40.410255] EAX: 0001 EBX: 0002 ECX: 009e EDX: 0001
[   40.410255] ESI: 0003 EDI: c0547f18 EBP: de52bdbc ESP: de52bd8c
[   40.410255]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   40.410255] Process modprobe (pid: 1115, ti=de52a000 task=de616000 
task.ti=de52a000)
[   40.410255] Stack: c0528d00 de52bda8 df2d9600 de52bdb0 df24bc20  
009e de52bdbc 
[   40.410255]0050 c0547ec0 c0547f18 df24bc00 de52bdf4 c025bc76 
0c64 de54ab7c 
[   40.410255]c050b760 000200d2 c0491758 000e 0202 e0055d75 
de616000 df24d660 
[   40.410255] Call Trace:
[   40.410255]  [c0104f2e] show_trace_log_lvl+0x1a/0x2f
[   40.410255]  [c0104fde] show_stack_log_lvl+0x9b/0xa3
[   40.410255]  [c010508a] show_registers+0xa4/0x1ba
[   40.410255]  [c01052bd] die+0x11d/0x1fe
[   40.410255]  [c0105428] do_trap+0x8a/0xa3
[   40.410255]  [c0105700] do_invalid_op+0x88/0x92
[   40.410255]  [c037d142] error_code+0x72/0x78
[   40.410255]  [c025bc76] ide_intr+0x166/0x1c9
[   40.410255]  [c014dbee] handle_IRQ_event+0x21/0x48
[   40.410255]  [c014ebac] handle_edge_irq+0xa8/0x10d
[   40.410255]  [c0106848] do_IRQ+0x5c/0x78
[   40.410255]  [c010494f] common_interrupt+0x23/0x28
[   40.410255]  [c014207c] sys_init_module+0x29d/0x18e1
[   40.410255]  [c0103f3e] sysenter_past_esp+0x5f/0x85
[   40.410255]  ===
[   40.410255] Code: f6 45 f0 08 8b 92 98 00 00 00 89 55 e8 75 3e b8 80 e5 4c 
c0 e8 81 6d 32 e0 31 c9 31 d2 89 c3 8b 45 d8 e8 bf 1e 17 e0 85 c0 74 04 0f 0b 
eb fe 8b 47 2c 89 da 8b 40 08 c7 40 1c 00 00 00 00 b8 80 
[   40.410255] EIP: [e0055e70] cdrom_newpc_intr+0xfb/0x29f [ide_cd] SS:ESP 
0068:de52bd8c
[   40.410255] Kernel panic - not syncing: Fatal exception in interrupt

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170

2007-09-06 Thread Florian Lohoff
On Thu, Sep 06, 2007 at 02:11:46PM +0530, Satyam Sharma wrote:
> On Thu, 6 Sep 2007, Herbert Xu wrote:
> 
> > On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> > > 
> > > > > [  382.529041]  [] dev_close+0x24/0x67
> > > > > [  382.529052]  [] ieee80211_master_stop+0x4a/0x6d 
> > > > > [mac80211]
> > 
> > This is where the bug is.  You cannot call dev_close from an
> > atomic context as i33380211_master_stop does it within spin
> > locks.
> 
> Doh, of course! I must be blind ... and wait_for_completion()'s
> might_sleep() clearly didn't trigger earlier because Florian must've
> had CONFIG_DEBUG_SPINLOCK_SLEEP off in his .config ...

# CONFIG_DEBUG_SPINLOCK_SLEEP is not set

Exactly ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


BUG: scheduling while atomic: ifconfig/0x00000002/4170

2007-09-02 Thread Florian Lohoff
otocol family 31
[   19.214640] Bluetooth: HCI device and connection manager initialized
[   19.214737] Bluetooth: HCI socket layer initialized
[   19.257180] Bluetooth: HCI USB driver ver 2.9
[   19.257349] usbcore: registered new interface driver hci_usb
[   19.751313] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0e10036532e4]
[   50.113619] Adding 979924k swap on /dev/sda5.  Priority:-1 extents:1 
across:979924k
[   50.163229] EXT3 FS on sda6, internal journal
[   64.870417] NET: Registered protocol family 10
[   64.870613] lo: Disabled Privacy Extensions
[   71.028607] Bluetooth: L2CAP ver 2.8
[   71.028615] Bluetooth: L2CAP socket layer initialized
[   71.168926] Bluetooth: RFCOMM socket layer initialized
[   71.169019] Bluetooth: RFCOMM TTY layer initialized
[   71.169054] Bluetooth: RFCOMM ver 1.8
[   71.539346] ADDRCONF(NETDEV_UP): wlan0_rename: link is not ready
[   71.737809] sky2 eth0: enabling interface
[   71.740794] sky2 eth0: ram buffer 0K
[   71.741733] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  142.968449] wlan0_rename: Initial auth_alg=0
[  142.968461] wlan0_rename: authenticate with AP 00:0c:41:de:12:e1
[  142.976883] wlan0_rename: RX authentication from 00:0c:41:de:12:e1 (alg=0 
transaction=2 status=0)
[  142.976891] wlan0_rename: authenticated
[  142.976895] wlan0_rename: associate with AP 00:0c:41:de:12:e1
[  142.979389] wlan0_rename: authentication frame received from 
00:0c:41:de:12:e1, but not in authenticate state - ignored
[  142.980404] wlan0_rename: RX AssocResp from 00:0c:41:de:12:e1 (capab=0x401 
status=0 aid=1)
[  142.980412] wlan0_rename: associated
[  142.982914] ADDRCONF(NETDEV_CHANGE): wlan0_rename: link becomes ready
[  148.291754] ICMPv6 NA: someone advertises our address on wlan0_rename!
[  151.386585] wlan0_rename: duplicate address detected!
[  382.517007] BUG: scheduling while atomic: ifconfig/0x0002/4170
[  382.517029]  [] __sched_text_start+0x84/0x71c
[  382.517047]  [] __sched_text_start+0x702/0x71c
[  382.517065]  [] link_path_walk+0xa9/0xb3
[  382.517079]  [] wait_for_completion+0x65/0x9b
[  382.517090]  [] default_wake_function+0x0/0xc
[  382.517103]  [] synchronize_rcu+0x2a/0x2f
[  382.517115]  [] wakeme_after_rcu+0x0/0x8
[  382.517127]  [] dev_deactivate+0x89/0x9c
[  382.517138]  [] dev_close+0x24/0x67
[  382.517150]  [] ieee80211_master_stop+0x4a/0x6d [mac80211]
[  382.517176]  [] dev_close+0x4b/0x67
[  382.517183]  [] dev_change_flags+0x9d/0x14e
[  382.517193]  [] devinet_ioctl+0x224/0x532
[  382.517201]  [] dev_ifsioc+0x113/0x396
[  382.517208]  [] dev_load+0x24/0x4b
[  382.517214]  [] sock_ioctl+0x0/0x1be
[  382.517233]  [] sock_ioctl+0x19f/0x1be
[  382.517239]  [] do_page_fault+0x269/0x58e
[  382.517246]  [] sock_ioctl+0x0/0x1be
[  382.517254]  [] do_ioctl+0x1f/0x62
[  382.517263]  [] vfs_ioctl+0x237/0x249
[  382.517270]  [] do_sys_open+0xbb/0xc5
[  382.517280]  [] sys_ioctl+0x33/0x4d
[  382.517288]  [] sysenter_past_esp+0x5f/0x85
[  382.517303]  ===
[  382.528958] BUG: scheduling while atomic: ifconfig/0x0002/4170
[  382.528972]  [] __sched_text_start+0x84/0x71c
[  382.528996]  [] wait_for_completion+0x65/0x9b
[  382.529005]  [] default_wake_function+0x0/0xc
[  382.529014]  [] synchronize_rcu+0x2a/0x2f
[  382.529021]  [] wakeme_after_rcu+0x0/0x8
[  382.529031]  [] dev_deactivate+0x89/0x9c
[  382.529041]  [] dev_close+0x24/0x67
[  382.529052]  [] ieee80211_master_stop+0x4a/0x6d [mac80211]
[  382.529077]  [] dev_close+0x4b/0x67
[  382.529088]  [] dev_change_flags+0x9d/0x14e
[  382.529101]  [] devinet_ioctl+0x224/0x532
[  382.529111]  [] dev_ifsioc+0x113/0x396
[  382.529122]  [] dev_load+0x24/0x4b
[  382.529132]  [] sock_ioctl+0x0/0x1be
[  382.529153]  [] sock_ioctl+0x19f/0x1be
[  382.529164]  [] do_page_fault+0x269/0x58e
[  382.529174]  [] sock_ioctl+0x0/0x1be
[  382.529187]  [] do_ioctl+0x1f/0x62
[  382.529201]  [] vfs_ioctl+0x237/0x249
[  382.529211]  [] do_sys_open+0xbb/0xc5
[  382.529224]  [] sys_ioctl+0x33/0x4d
[  382.529235]  [] sysenter_past_esp+0x5f/0x85
[  382.529253]  =======
[  382.530962] Freeing alive inet6 address cd98f600
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


BUG: scheduling while atomic: ifconfig/0x00000002/4170

2007-09-02 Thread Florian Lohoff
] Bluetooth: HCI socket layer initialized
[   19.257180] Bluetooth: HCI USB driver ver 2.9
[   19.257349] usbcore: registered new interface driver hci_usb
[   19.751313] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0e10036532e4]
[   50.113619] Adding 979924k swap on /dev/sda5.  Priority:-1 extents:1 
across:979924k
[   50.163229] EXT3 FS on sda6, internal journal
[   64.870417] NET: Registered protocol family 10
[   64.870613] lo: Disabled Privacy Extensions
[   71.028607] Bluetooth: L2CAP ver 2.8
[   71.028615] Bluetooth: L2CAP socket layer initialized
[   71.168926] Bluetooth: RFCOMM socket layer initialized
[   71.169019] Bluetooth: RFCOMM TTY layer initialized
[   71.169054] Bluetooth: RFCOMM ver 1.8
[   71.539346] ADDRCONF(NETDEV_UP): wlan0_rename: link is not ready
[   71.737809] sky2 eth0: enabling interface
[   71.740794] sky2 eth0: ram buffer 0K
[   71.741733] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  142.968449] wlan0_rename: Initial auth_alg=0
[  142.968461] wlan0_rename: authenticate with AP 00:0c:41:de:12:e1
[  142.976883] wlan0_rename: RX authentication from 00:0c:41:de:12:e1 (alg=0 
transaction=2 status=0)
[  142.976891] wlan0_rename: authenticated
[  142.976895] wlan0_rename: associate with AP 00:0c:41:de:12:e1
[  142.979389] wlan0_rename: authentication frame received from 
00:0c:41:de:12:e1, but not in authenticate state - ignored
[  142.980404] wlan0_rename: RX AssocResp from 00:0c:41:de:12:e1 (capab=0x401 
status=0 aid=1)
[  142.980412] wlan0_rename: associated
[  142.982914] ADDRCONF(NETDEV_CHANGE): wlan0_rename: link becomes ready
[  148.291754] ICMPv6 NA: someone advertises our address on wlan0_rename!
[  151.386585] wlan0_rename: duplicate address detected!
[  382.517007] BUG: scheduling while atomic: ifconfig/0x0002/4170
[  382.517029]  [c032bf5c] __sched_text_start+0x84/0x71c
[  382.517047]  [c032c5da] __sched_text_start+0x702/0x71c
[  382.517065]  [c0174a6c] link_path_walk+0xa9/0xb3
[  382.517079]  [c032c6ad] wait_for_completion+0x65/0x9b
[  382.517090]  [c011f0a2] default_wake_function+0x0/0xc
[  382.517103]  [c01334cf] synchronize_rcu+0x2a/0x2f
[  382.517115]  [c0133091] wakeme_after_rcu+0x0/0x8
[  382.517127]  [c02d5f4f] dev_deactivate+0x89/0x9c
[  382.517138]  [c02c8abc] dev_close+0x24/0x67
[  382.517150]  [e01f402b] ieee80211_master_stop+0x4a/0x6d [mac80211]
[  382.517176]  [c02c8ae3] dev_close+0x4b/0x67
[  382.517183]  [c02c7f47] dev_change_flags+0x9d/0x14e
[  382.517193]  [c03058c8] devinet_ioctl+0x224/0x532
[  382.517201]  [c02c9589] dev_ifsioc+0x113/0x396
[  382.517208]  [c02c8d59] dev_load+0x24/0x4b
[  382.517214]  [c02be61d] sock_ioctl+0x0/0x1be
[  382.517233]  [c02be7bc] sock_ioctl+0x19f/0x1be
[  382.517239]  [c011a993] do_page_fault+0x269/0x58e
[  382.517246]  [c02be61d] sock_ioctl+0x0/0x1be
[  382.517254]  [c0176787] do_ioctl+0x1f/0x62
[  382.517263]  [c0176a01] vfs_ioctl+0x237/0x249
[  382.517270]  [c016b7d8] do_sys_open+0xbb/0xc5
[  382.517280]  [c0176a46] sys_ioctl+0x33/0x4d
[  382.517288]  [c0103e52] sysenter_past_esp+0x5f/0x85
[  382.517303]  ===
[  382.528958] BUG: scheduling while atomic: ifconfig/0x0002/4170
[  382.528972]  [c032bf5c] __sched_text_start+0x84/0x71c
[  382.528996]  [c032c6ad] wait_for_completion+0x65/0x9b
[  382.529005]  [c011f0a2] default_wake_function+0x0/0xc
[  382.529014]  [c01334cf] synchronize_rcu+0x2a/0x2f
[  382.529021]  [c0133091] wakeme_after_rcu+0x0/0x8
[  382.529031]  [c02d5f4f] dev_deactivate+0x89/0x9c
[  382.529041]  [c02c8abc] dev_close+0x24/0x67
[  382.529052]  [e01f402b] ieee80211_master_stop+0x4a/0x6d [mac80211]
[  382.529077]  [c02c8ae3] dev_close+0x4b/0x67
[  382.529088]  [c02c7f47] dev_change_flags+0x9d/0x14e
[  382.529101]  [c03058c8] devinet_ioctl+0x224/0x532
[  382.529111]  [c02c9589] dev_ifsioc+0x113/0x396
[  382.529122]  [c02c8d59] dev_load+0x24/0x4b
[  382.529132]  [c02be61d] sock_ioctl+0x0/0x1be
[  382.529153]  [c02be7bc] sock_ioctl+0x19f/0x1be
[  382.529164]  [c011a993] do_page_fault+0x269/0x58e
[  382.529174]  [c02be61d] sock_ioctl+0x0/0x1be
[  382.529187]  [c0176787] do_ioctl+0x1f/0x62
[  382.529201]  [c0176a01] vfs_ioctl+0x237/0x249
[  382.529211]  [c016b7d8] do_sys_open+0xbb/0xc5
[  382.529224]  [c0176a46] sys_ioctl+0x33/0x4d
[  382.529235]  [c0103e52] sysenter_past_esp+0x5f/0x85
[  382.529253]  ===
[  382.530962] Freeing alive inet6 address cd98f600
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: 2.6.23-rc1 sky2 boot crash in sky2_mac_intr

2007-07-25 Thread Florian Lohoff
On Wed, Jul 25, 2007 at 01:30:31AM +0200, Michal Piotrowski wrote:
> >I'll try the above and keep you posted. The crash itself seems to be a
> >2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
> >which i was running before.
> 
> Can you try to figure out what is causing this crash and then use 
> git-bisect?

Are there so many changes between 2.6.22-rc5 and 2.6.23-rc1 for the sky2?

As the crash is not that reproducible, just occasionally on boot i guess
bisecting is more or less waste of time.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: 2.6.23-rc1 sky2 boot crash in sky2_mac_intr

2007-07-25 Thread Florian Lohoff
On Wed, Jul 25, 2007 at 01:30:31AM +0200, Michal Piotrowski wrote:
 I'll try the above and keep you posted. The crash itself seems to be a
 2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
 which i was running before.
 
 Can you try to figure out what is causing this crash and then use 
 git-bisect?

Are there so many changes between 2.6.22-rc5 and 2.6.23-rc1 for the sky2?

As the crash is not that reproducible, just occasionally on boot i guess
bisecting is more or less waste of time.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: 2.6.23-rc1 sky2 boot crash in sky2_mac_intr

2007-07-24 Thread Florian Lohoff
On Tue, Jul 24, 2007 at 09:50:08AM +0100, Stephen Hemminger wrote:
> The problem is related to power management. The PHY has a number of PCI 
> configuration
> registers for power control, and the function of these changes based on the 
> version and
> revision of the chip. The driver does work on older versions of the EC-U, in
> Fujitsu laptop's, it is just the new rev that is broken.
> 
> The driver should probably fail smarter (by not loading) if the PHY isn't 
> powered
> up correctly, but that doesn't help your problem.
> 
> The vendor has provided me with documentation on many versions
> of the chip, but I don't have doc's on the lastest revision differences of 
> the EC Ultra, 
> so a proper solution is not easily available.  The best method for resolving 
> this would
> be to first try the vendor driver version of sk98lin and see if that fixes 
> it. If so,
> then it is easy to change sky2, to match the phy setup in the vendor driver.
> Another possibility is to look for places in sky2 driver where there are 
> places
> that compare version/revision.
> 
> The most likely bits that need to change are in PCI registers: 0x80, 0x84 and 
> 0x88
> You could also load the windows driver and dump PCI config space (with lspci 
> from
> cygwin), and see what the settings are there.
> 
> I am away from my office for a month, and therefore away from any sky2
> hardware for testing. 

I'll try the above and keep you posted. The crash itself seems to be a
2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
which i was running before.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


2.6.23-rc1 sky2 boot crash in sky2_mac_intr

2007-07-24 Thread Florian Lohoff

Hi,
i am seeing irregular crashes on boot in the sky2_mac_intr. This is an
Fujitsu Siemens Lifebook E8110 with a Core Duo. Currently i suspect some
strange BIOS issues as the issues i see with the sky2 aka parity errors
etc i also see sometimes with the integrated ipw3945 which complains
about firmware errors. It seems the BIOS randomly fails to initialize
all the hardware. To reproduce this crash and catch it on the serial
console it took me around 12 boots. The machine is stable once correctly
booted and i work most of the day on it.

[   46.479939] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> 
IRQ 19
[   46.568569] sky2 :02:00.0: v1.16 addr 0xf000 irq 19 Yukon-EC Ultra 
(0xb4) rev 2
[   46.664555] sky2 eth0: addr 00:17:42:13:45:8c

[   61.958741] sky2 eth1: enabling interface
[   62.010834] sky2 eth1: phy write timeout
[   62.060319] sky2 eth1: phy write timeout
[   62.109819] sky2 eth1: phy write timeout
[   62.159330] sky2 eth1: phy write timeout
[   62.208811] sky2 eth1: phy write timeout
[   62.258306] sky2 eth1: phy write timeout
[   62.307786] sky2 eth1: phy write timeout
[   62.357323] sky2 eth1: phy write timeout
[   62.406820] sky2 eth1: phy write timeout
[   62.456304] sky2 eth1: phy write timeout
[   62.505796] sky2 eth1: phy write timeout
[   62.555275] sky2 eth1: phy write timeout
[   62.604766] sky2 eth1: phy write timeout
[   62.654259] sky2 eth1: phy write timeout
[   62.703736] sky2 eth1: phy write timeout
[   62.750601] sky2 :02:00.0: error interrupt status=0x
[   62.822361] sky2 :02:00.0: PCI hardware error (0x)
[   62.887897] sky2 :02:00.0: PCI Express error (0x)
[   62.956548] sky2 eth1: hw error interrupt status 0x
[   63.023112] sky2 eth1: ram data read parity error
[   63.079308] sky2 eth1: ram data write parity error
[   63.136536] sky2 eth1: MAC parity error
[   63.182382] BUG: unable to handle kernel NULL pointer dereference at virtual 
address 020c
[   63.284354]  printing eip:
[   63.316658] e004c528
[   63.342729] *pde = 
[   63.376072] Oops:  [#1]
[   63.409407] PREEMPT SMP 
[   63.439704] Modules linked in: sbp2 hci_usb bluetooth snd_hda_intel 
snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi 
snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device pcmcia ipw3945 
smsc_ircc2 ehci_hcd snd ieee80211 ieee80211_crypt uhci_hcd ohci1394 sdhci 
yenta_socket rsrc_nonstatic parport_pc parport irda ieee1394 mmc_core ide_cd 
usbcore pcmcia_core crc_ccitt snd_page_alloc sky2
[   63.883256] CPU:0
[   63.883257] EIP:0060:[]Not tainted VLI
[   63.883258] EFLAGS: 00010202   (2.6.23-rc1 #1)
[   64.026826] EIP is at sky2_mac_intr+0x14/0xac [sky2]
[   64.086857] eax: 0080   ebx: 0001   ecx: 0008   edx: 
[   64.167942] esi: df4d6c00   edi:    ebp:    esp: de3c1dbc
[   64.249024] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[   64.318683] Process ifconfig (pid: 1878, ti=de3c task=df43b740 
task.ti=de3c)
[   64.409113] Stack: e004e1e0 e0051fa5 df4d5000  c15ae914 00042010 
  
[   64.509381]e004f737 e00521b2 e00520cf c15ae914  c040fbe0 
de3c1e4c df4d5000 
[   64.609644]df4d6c00  00ff c02c3be6 c13c5400 c02c9ea9 
c13d9dc0 0287 
[   64.709905] Call Trace:
[   64.741230]  [] sky2_hw_error+0xf9/0x12a [sky2]
[   64.805757]  [] sky2_poll+0x1da/0xa88 [sky2]
[   64.867171]  [] kfree_skbmem+0x8/0x61
[   64.921311]  [] net_tx_action+0x61/0xd0
[   64.977521]  [] net_tx_action+0x61/0xd0
[   65.033734]  [] net_tx_action+0x61/0xd0
[   65.089942]  [] net_rx_action+0x92/0x1b5
[   65.147197]  [] __do_softirq+0x58/0xba
[   65.202372]  [] do_softirq+0x31/0x36
[   65.255472]  [] local_bh_enable_ip+0x36/0x56
[   65.316876]  [] sky2_up+0x234/0x5df [sky2]
[   65.376203]  [] dev_open+0x2e/0x68
[   65.427223]  [] dev_change_flags+0x9d/0x14e
[   65.487590]  [] devinet_ioctl+0x224/0x532
[   65.545874]  [] dev_ifsioc+0x113/0x396
[   65.601043]  [] dev_load+0x24/0x4b
[   65.652060]  [] sock_ioctl+0x0/0x1be
[   65.705159]  [] sock_ioctl+0x19f/0x1be
[   65.760329]  [] do_page_fault+0x269/0x58e
[   65.818613]  [] sock_ioctl+0x0/0x1be
[   65.871708]  [] do_ioctl+0x1f/0x62
[   65.922732]  [] vfs_ioctl+0x237/0x249
[   65.976869]  [] sys_ioctl+0x33/0x4d
[   66.028925]  [] sysenter_past_esp+0x5f/0x85
[   66.089293]  [] pfkey_send_notify+0x41/0x226
[   66.150699]  ===
[   66.193363] Code: 05 e0 e8 da a2 0d e0 03 1f c7 03 00 04 00 00 83 c4 1c 5b 
5e 5f 5d c3 55 57 56 89 c6 53 89 d3 83 ec 10 8b 54 90 08 89 d8 c1 e0 07 <8b> ba 
0c 02 00 00 89 44 24 0c 05 08 0f 00 00 03 06 f6 47 0d 02 
[   66.422172] EIP: [] sky2_mac_intr+0x14/0xac [sky2] SS:ESP 
0068:de3c1dbc
[   66.511713] Kernel panic - not syncing: Fatal exception in interrupt

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to 

2.6.23-rc1 sky2 boot crash in sky2_mac_intr

2007-07-24 Thread Florian Lohoff
] Kernel panic - not syncing: Fatal exception in interrupt

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: 2.6.23-rc1 sky2 boot crash in sky2_mac_intr

2007-07-24 Thread Florian Lohoff
On Tue, Jul 24, 2007 at 09:50:08AM +0100, Stephen Hemminger wrote:
 The problem is related to power management. The PHY has a number of PCI 
 configuration
 registers for power control, and the function of these changes based on the 
 version and
 revision of the chip. The driver does work on older versions of the EC-U, in
 Fujitsu laptop's, it is just the new rev that is broken.
 
 The driver should probably fail smarter (by not loading) if the PHY isn't 
 powered
 up correctly, but that doesn't help your problem.
 
 The vendor has provided me with documentation on many versions
 of the chip, but I don't have doc's on the lastest revision differences of 
 the EC Ultra, 
 so a proper solution is not easily available.  The best method for resolving 
 this would
 be to first try the vendor driver version of sk98lin and see if that fixes 
 it. If so,
 then it is easy to change sky2, to match the phy setup in the vendor driver.
 Another possibility is to look for places in sky2 driver where there are 
 places
 that compare version/revision.
 
 The most likely bits that need to change are in PCI registers: 0x80, 0x84 and 
 0x88
 You could also load the windows driver and dump PCI config space (with lspci 
 from
 cygwin), and see what the settings are there.
 
 I am away from my office for a month, and therefore away from any sky2
 hardware for testing. 

I'll try the above and keep you posted. The crash itself seems to be a
2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
which i was running before.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: Linux, tcpdump and vlan

2007-07-20 Thread Florian Lohoff
On Wed, Jul 18, 2007 at 12:34:33PM -0700, andrei radulescu-banu wrote:
> 
> Dear kernel networking gurus, 
> 
> I am trying to understand why tcpdump does not work properly for vlan packets 
> on linux. Here is the existing behavior, observed with:
>   - kernel 2.6.16,   
> - e1000 driver  
> - libpcap 0.9.6  
> - tcpdump 3.9.6 
>   
> 
> The e1000 driver has two modes when handling vlan frames:  
> (A) Default mode, when   
> - on rx, the mac includes vlan headers   
> - on tx, the mac expects tx frames to include vlan headers.   
> (B) Vlan hw accelerated mode, when:  
> - on rx, the mac does not include vlan headers, and instead passes vlan tag 
> information in the status field of the ring buffer
>   - on tx, the mac expects no vlan headers, and instead expects vlan tag 
> information to be passed in the status field of the ring buffer

I have seen similar behaviour. Once the kernel is compiled with VLAN
support the e1000 driver drops the vlan tag completely even when no
vlans are configured on that port. I would consider this beeing a bug
that enableing a kernel option changes behaviour even if the feature is
not in use.

As i was tracing dot1qinq i could actually see that only the outer
vlan tag was beeing dropped.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: Linux, tcpdump and vlan

2007-07-20 Thread Florian Lohoff
On Wed, Jul 18, 2007 at 12:34:33PM -0700, andrei radulescu-banu wrote:
 
 Dear kernel networking gurus, 
 
 I am trying to understand why tcpdump does not work properly for vlan packets 
 on linux. Here is the existing behavior, observed with:
   - kernel 2.6.16,   
 - e1000 driver  
 - libpcap 0.9.6  
 - tcpdump 3.9.6 
   
 
 The e1000 driver has two modes when handling vlan frames:  
 (A) Default mode, when   
 - on rx, the mac includes vlan headers   
 - on tx, the mac expects tx frames to include vlan headers.   
 (B) Vlan hw accelerated mode, when:  
 - on rx, the mac does not include vlan headers, and instead passes vlan tag 
 information in the status field of the ring buffer
   - on tx, the mac expects no vlan headers, and instead expects vlan tag 
 information to be passed in the status field of the ring buffer

I have seen similar behaviour. Once the kernel is compiled with VLAN
support the e1000 driver drops the vlan tag completely even when no
vlans are configured on that port. I would consider this beeing a bug
that enableing a kernel option changes behaviour even if the feature is
not in use.

As i was tracing dot1qinq i could actually see that only the outer
vlan tag was beeing dropped.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: [6/6] 2.6.21-rc3: known regressions

2007-03-14 Thread Florian Lohoff
On Wed, Mar 14, 2007 at 12:44:17PM +0100, Adrian Bunk wrote:
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > Subject: Clocksource tsc unstable (delta = -154983451 ns)
> > > References : http://lkml.org/lkml/2007/3/9/271
> > > Submitter  : Jiri Slaby <[EMAIL PROTECTED]>
> > > Status : unknown
> > 
> > That's not a regression. That's an informal message, when the TSC
> > watchdog detects that the TSC is unreliable. 
> 
> Looking at [1], there's also be a probably related "doesn't boot" 
> problem.
> My first guess would be commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
> "clocksource init adjustments (fix bug #7426)".
> 
> Jiri, is the message also present with 2.6.21-rc2 (at a different place 
> of the dmesg) for you?

With the current git of today the halt on boot is gone. I am running 
it now ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Re: [6/6] 2.6.21-rc3: known regressions

2007-03-14 Thread Florian Lohoff
On Wed, Mar 14, 2007 at 12:44:17PM +0100, Adrian Bunk wrote:
   Due to the huge amount of recipients, please trim the Cc when answering.
   Subject: Clocksource tsc unstable (delta = -154983451 ns)
   References : http://lkml.org/lkml/2007/3/9/271
   Submitter  : Jiri Slaby [EMAIL PROTECTED]
   Status : unknown
  
  That's not a regression. That's an informal message, when the TSC
  watchdog detects that the TSC is unreliable. 
 
 Looking at [1], there's also be a probably related doesn't boot 
 problem.
 My first guess would be commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
 clocksource init adjustments (fix bug #7426).
 
 Jiri, is the message also present with 2.6.21-rc2 (at a different place 
 of the dmesg) for you?

With the current git of today the halt on boot is gone. I am running 
it now ...

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Boot fails with 2.6.20-rc3 / git-current Was: 2.6.20-rc3: Clocksource tsc unstable

2007-03-13 Thread Florian Lohoff
On Fri, Mar 09, 2007 at 06:41:45PM +0100, Jiri Slaby wrote:
> Hi.
> 
> I got this message after suspend;resume on my notebook
> Clocksource tsc unstable (delta = -154983451 ns)
> 

I am getting the exact same line on bootup on my Fujitsu Siemens
Lifebook E8110. After that line the boot halts with current git:

Last lines on current git were:

IPMI System Interface driver
Clocksource tsc unstable ( delta = -160251929ns )

Now running:
Linux laptop 2.6.21-rc2 #1 SMP PREEMPT Thu Mar 1 07:41:52 CET 2007 i686 
GNU/Linux

which comes up with the same line when initializing IDE but continues
to run:

[9.912917] ICH7: IDE controller at PCI slot :00:1f.1
[9.913025] ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> 
IRQ 20
[9.913210] ICH7: chipset revision 2
[9.913300] ICH7: not 100% native mode: will probe irqs later
[9.913403] ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, 
hdb:pio
[9.913637] Probing IDE interface ide0...
[9.997936] Clocksource tsc unstable (delta = -430882190 ns)
[   10.002393] hda: MATSHITAUJ-841Db, ATAPI CD/DVD-ROM drive
[   10.003539] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0e10036532e4]
[   10.052945] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

CPU info:

[EMAIL PROTECTED]:~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 14
model name  : Genuine Intel(R) CPU   T2400  @ 1.83GHz
stepping: 8
cpu MHz : 1333.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor 
vmx est tm2 xtpr
bogomips: 3662.23
clflush size: 64

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 14
model name  : Genuine Intel(R) CPU   T2400  @ 1.83GHz
stepping: 8
cpu MHz : 1333.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor 
vmx est tm2 xtpr
bogomips: 3657.63
clflush size    : 64

-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


Boot fails with 2.6.20-rc3 / git-current Was: 2.6.20-rc3: Clocksource tsc unstable

2007-03-13 Thread Florian Lohoff
On Fri, Mar 09, 2007 at 06:41:45PM +0100, Jiri Slaby wrote:
 Hi.
 
 I got this message after suspend;resume on my notebook
 Clocksource tsc unstable (delta = -154983451 ns)
 

I am getting the exact same line on bootup on my Fujitsu Siemens
Lifebook E8110. After that line the boot halts with current git:

Last lines on current git were:

IPMI System Interface driver
Clocksource tsc unstable ( delta = -160251929ns )

Now running:
Linux laptop 2.6.21-rc2 #1 SMP PREEMPT Thu Mar 1 07:41:52 CET 2007 i686 
GNU/Linux

which comes up with the same line when initializing IDE but continues
to run:

[9.912917] ICH7: IDE controller at PCI slot :00:1f.1
[9.913025] ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - 
IRQ 20
[9.913210] ICH7: chipset revision 2
[9.913300] ICH7: not 100% native mode: will probe irqs later
[9.913403] ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, 
hdb:pio
[9.913637] Probing IDE interface ide0...
[9.997936] Clocksource tsc unstable (delta = -430882190 ns)
[   10.002393] hda: MATSHITAUJ-841Db, ATAPI CD/DVD-ROM drive
[   10.003539] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0e10036532e4]
[   10.052945] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

CPU info:

[EMAIL PROTECTED]:~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 14
model name  : Genuine Intel(R) CPU   T2400  @ 1.83GHz
stepping: 8
cpu MHz : 1333.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor 
vmx est tm2 xtpr
bogomips: 3662.23
clflush size: 64

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 14
model name  : Genuine Intel(R) CPU   T2400  @ 1.83GHz
stepping: 8
cpu MHz : 1333.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor 
vmx est tm2 xtpr
bogomips: 3657.63
clflush size: 64

-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


2.6.20-rc4 sky2 unsupported chip type 0xff / phy write timeout

2007-01-10 Thread Florian Lohoff

Hi,
i have random problems after fresh boot with the onboard sky2 on an
Fujitsu Siemens Lifebook E8110. With 2.6.18-686-3 from the Debian repository i 
see
random crashes on boot - see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107

With a 

Linux machine 2.6.20-rc4 #0 SMP PREEMPT Mon Jan 8 15:18:15 CET 2007 
i686 GNU/Linux

i dont see crashes now but instead i see on random boots:

[   12.412000] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, 
low) -> IRQ 16
[   12.412000] PCI: Setting latency timer of device :02:00.0 to 64
[   12.412000] sky2 v1.10 addr 0xf000 irq 16 Yukon-EC Ultra (0xb4) 
rev 2
[   12.412000] sky2 eth0: addr 00:17:42:13:45:8c
[   24.548000] sky2 eth1: enabling interface
[   24.552000] sky2 eth1: phy write timeout
[   24.556000] sky2 eth1: phy write timeout
[   24.556000] sky2 eth1: phy write timeout
[   24.56] sky2 eth1: phy write timeout
[   24.56] sky2 eth1: phy write timeout
[   24.564000] sky2 eth1: phy write timeout
[   24.564000] sky2 eth1: phy write timeout
[   24.568000] sky2 eth1: phy write timeout
[   24.568000] sky2 eth1: phy write timeout
[   24.572000] sky2 eth1: phy write timeout
[   24.572000] sky2 eth1: ram buffer 1020K

Afterwards the interface is not usable as one would have expected. 
rmmod/modprobe later:

[  186.536000] sky2 eth1: disabling interface
[  186.536000] sky2 eth1: phy write timeout
[  186.564000] ACPI: PCI interrupt for device :02:00.0 disabled
[  190.464000] PCI: Enabling device :02:00.0 ( -> 0003)
[  190.464000] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, 
low) -> IRQ 16
[  190.464000] PCI: Setting latency timer of device :02:00.0 to 64
[  190.464000] sky2 :02:00.0: unsupported chip type 0xff
[  190.464000] ACPI: PCI interrupt for device :02:00.0 disabled
[  190.464000] sky2: probe of :02:00.0 failed with error -95

On a working boot i see:

[   12.236000] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, 
low) -> IRQ 16
[   12.236000] PCI: Setting latency timer of device :02:00.0 to 64
[   12.236000] sky2 v1.10 addr 0xf000 irq 16 Yukon-EC Ultra (0xb4) 
rev 2
[   12.24] sky2 eth1: addr 00:17:42:13:45:8c
[   24.552000] sky2 eth1: enabling interface
[   24.556000] sky2 eth1: ram buffer 0K
[   26.20] sky2 eth1: Link is up at 100 Mbps, full duplex, flow 
control none


lspci -vvvn

02:00.0 0200: 11ab:4363 (rev 12)
Subsystem: 10cf:139a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 

signature.asc
Description: Digital signature


2.6.20-rc4 sky2 unsupported chip type 0xff / phy write timeout

2007-01-10 Thread Florian Lohoff

Hi,
i have random problems after fresh boot with the onboard sky2 on an
Fujitsu Siemens Lifebook E8110. With 2.6.18-686-3 from the Debian repository i 
see
random crashes on boot - see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107

With a 

Linux machine 2.6.20-rc4 #0 SMP PREEMPT Mon Jan 8 15:18:15 CET 2007 
i686 GNU/Linux

i dont see crashes now but instead i see on random boots:

[   12.412000] ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, 
low) - IRQ 16
[   12.412000] PCI: Setting latency timer of device :02:00.0 to 64
[   12.412000] sky2 v1.10 addr 0xf000 irq 16 Yukon-EC Ultra (0xb4) 
rev 2
[   12.412000] sky2 eth0: addr 00:17:42:13:45:8c
[   24.548000] sky2 eth1: enabling interface
[   24.552000] sky2 eth1: phy write timeout
[   24.556000] sky2 eth1: phy write timeout
[   24.556000] sky2 eth1: phy write timeout
[   24.56] sky2 eth1: phy write timeout
[   24.56] sky2 eth1: phy write timeout
[   24.564000] sky2 eth1: phy write timeout
[   24.564000] sky2 eth1: phy write timeout
[   24.568000] sky2 eth1: phy write timeout
[   24.568000] sky2 eth1: phy write timeout
[   24.572000] sky2 eth1: phy write timeout
[   24.572000] sky2 eth1: ram buffer 1020K

Afterwards the interface is not usable as one would have expected. 
rmmod/modprobe later:

[  186.536000] sky2 eth1: disabling interface
[  186.536000] sky2 eth1: phy write timeout
[  186.564000] ACPI: PCI interrupt for device :02:00.0 disabled
[  190.464000] PCI: Enabling device :02:00.0 ( - 0003)
[  190.464000] ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, 
low) - IRQ 16
[  190.464000] PCI: Setting latency timer of device :02:00.0 to 64
[  190.464000] sky2 :02:00.0: unsupported chip type 0xff
[  190.464000] ACPI: PCI interrupt for device :02:00.0 disabled
[  190.464000] sky2: probe of :02:00.0 failed with error -95

On a working boot i see:

[   12.236000] ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, 
low) - IRQ 16
[   12.236000] PCI: Setting latency timer of device :02:00.0 to 64
[   12.236000] sky2 v1.10 addr 0xf000 irq 16 Yukon-EC Ultra (0xb4) 
rev 2
[   12.24] sky2 eth1: addr 00:17:42:13:45:8c
[   24.552000] sky2 eth1: enabling interface
[   24.556000] sky2 eth1: ram buffer 0K
[   26.20] sky2 eth1: Link is up at 100 Mbps, full duplex, flow 
control none


lspci -vvvn

02:00.0 0200: 11ab:4363 (rev 12)
Subsystem: 10cf:139a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 220
Region 0: Memory at f000 (64-bit, non-prefetchable) 
[size=16K]
Region 2: I/O ports at 2000 [size=256]
[virtual] Expansion ROM at 3800 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ 
Queue=0/0 Enable+
Address: fee0300c  Data: 4142
Capabilities: [e0] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, 
ExtTag-
Device: Latency L0s unlimited, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, 
Port 0
Link: Latency L0s 256ns, L1 unlimited
Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [100] Advanced Error Reporting

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature


[OOps] 2.6.11-rc3 rmmod ide-scsi

2005-02-08 Thread Florian Lohoff

Hi,
got this oops while unloading ide-scsi (rmmod segfaulted)

UP P4 1.7Ghz non Preempt, No HT, IDE DVD/CD-RW, IDE Disk, Vanilla
Kernel, (-chaos -> Debian make-kpkg --append-to-version=-chaos)

Linux chaos 2.6.11-rc3-chaos #1 Fri Feb 4 23:27:57 CET 2005 i686 GNU/Linux

Unable to handle kernel NULL pointer dereference at virtual address 01e0
 printing eip:
e089e539
*pde = 
Oops:  [#1]
Modules linked in: nls_iso8859_1 isofs autofs4 nfs lockd sunrpc snd_ens1371 
snd_rawmidi snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd 
snd_page_alloc e100 i2c_i801 i2c_core evdev usbhid uhci_hcd usbcore intel_agp 
agpgart sr_mod cdrom dm_mod ide_scsi scsi_mod eepro100 mii
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010002   (2.6.11-rc3-chaos) 
EIP is at idescsi_queue+0x119/0x400 [ide_scsi]
eax:    ebx: c0971a40   ecx: e08c4a30   edx: dedf8b00
esi: 1388   edi: c044e234   ebp: dedf8b54   esp: c910dc94
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 11757, threadinfo=c910c000 task=c9eec510)
Stack: dffef380 0020 0010 c0971a40 dedf8b00 d9546cb0 dedf8b68 deffcd80 
   01d4 c044e234 0293 dedf8b00 ded25400  e08c47cf dedf8b00 
   e08c4a30 e08c76d0 dedf8b88 dedf8b00 df692c00 ded25400 c1583030 e08caa9a 
Call Trace:
 [] scsi_dispatch_cmd+0x16f/0x250 [scsi_mod]
 [] scsi_done+0x0/0x30 [scsi_mod]
 [] scsi_times_out+0x0/0xc0 [scsi_mod]
 [] scsi_request_fn+0x1ca/0x380 [scsi_mod]
 [] __elv_add_request+0x78/0xc0
 [] blk_insert_request+0xa6/0xd0
 [] scsi_insert_special_req+0x38/0x40 [scsi_mod]
 [] scsi_wait_req+0x68/0xa0 [scsi_mod]
 [] scsi_wait_done+0x0/0x60 [scsi_mod]
 [] sr_do_ioctl+0x92/0x2a0 [sr_mod]
 [] sr_packet+0x25/0x40 [sr_mod]
 [] cdrom_get_disc_info+0x65/0xb0 [cdrom]
 [] cdrom_mrw_exit+0x1b/0x70 [cdrom]
 [] unregister_cdrom+0x83/0xb0 [cdrom]
 [] sr_kref_release+0x2a/0x50 [sr_mod]
 [] sr_kref_release+0x0/0x50 [sr_mod]
 [] kref_put+0x39/0xa0
 [] kobject_put+0x1f/0x30
 [] sr_remove+0x39/0x4b [sr_mod]
 [] sr_kref_release+0x0/0x50 [sr_mod]
 [] device_release_driver+0x86/0x90
 [] bus_remove_device+0x64/0xb0
 [] device_del+0x5d/0xa0
 [] scsi_remove_device+0x4f/0xb0 [scsi_mod]
 [] scsi_forget_host+0x2a/0x50 [scsi_mod]
 [] scsi_remove_host+0x19/0x80 [scsi_mod]
 [] idescsi_cleanup+0x4d/0x60 [ide_scsi]
 [] ide_unregister_driver+0x5e/0x90
 [] try_stop_module+0x28/0x30
 [] exit_idescsi_module+0xf/0x11 [ide_scsi]
 [] sys_delete_module+0x144/0x180
 [] do_munmap+0xf0/0x160
 [] sys_munmap+0x44/0x70
 [] syscall_call+0x7/0xb
Code: 8b 54 24 3c 8b 42 64 89 53 2c 89 43 14 89 43 0c 8b 4c 24 40 89 4b 30 a1 
a0 0d 35 c0 8b 72 3c 01 f0 89 43 38 8b 7c 24 24 8b 47 20 <8b> 80 e0 01 00 00 a8 
01 74 05 0f ba 6b 34 02 8b 43 1c 89 44 24 

-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgpRHRt4MHkWV.pgp
Description: PGP signature


[OOps] 2.6.11-rc3 rmmod ide-scsi

2005-02-08 Thread Florian Lohoff

Hi,
got this oops while unloading ide-scsi (rmmod segfaulted)

UP P4 1.7Ghz non Preempt, No HT, IDE DVD/CD-RW, IDE Disk, Vanilla
Kernel, (-chaos - Debian make-kpkg --append-to-version=-chaos)

Linux chaos 2.6.11-rc3-chaos #1 Fri Feb 4 23:27:57 CET 2005 i686 GNU/Linux

Unable to handle kernel NULL pointer dereference at virtual address 01e0
 printing eip:
e089e539
*pde = 
Oops:  [#1]
Modules linked in: nls_iso8859_1 isofs autofs4 nfs lockd sunrpc snd_ens1371 
snd_rawmidi snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd 
snd_page_alloc e100 i2c_i801 i2c_core evdev usbhid uhci_hcd usbcore intel_agp 
agpgart sr_mod cdrom dm_mod ide_scsi scsi_mod eepro100 mii
CPU:0
EIP:0060:[e089e539]Not tainted VLI
EFLAGS: 00010002   (2.6.11-rc3-chaos) 
EIP is at idescsi_queue+0x119/0x400 [ide_scsi]
eax:    ebx: c0971a40   ecx: e08c4a30   edx: dedf8b00
esi: 1388   edi: c044e234   ebp: dedf8b54   esp: c910dc94
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 11757, threadinfo=c910c000 task=c9eec510)
Stack: dffef380 0020 0010 c0971a40 dedf8b00 d9546cb0 dedf8b68 deffcd80 
   01d4 c044e234 0293 dedf8b00 ded25400  e08c47cf dedf8b00 
   e08c4a30 e08c76d0 dedf8b88 dedf8b00 df692c00 ded25400 c1583030 e08caa9a 
Call Trace:
 [e08c47cf] scsi_dispatch_cmd+0x16f/0x250 [scsi_mod]
 [e08c4a30] scsi_done+0x0/0x30 [scsi_mod]
 [e08c76d0] scsi_times_out+0x0/0xc0 [scsi_mod]
 [e08caa9a] scsi_request_fn+0x1ca/0x380 [scsi_mod]
 [c0233858] __elv_add_request+0x78/0xc0
 [c0236446] blk_insert_request+0xa6/0xd0
 [e08c97b8] scsi_insert_special_req+0x38/0x40 [scsi_mod]
 [e08c9a28] scsi_wait_req+0x68/0xa0 [scsi_mod]
 [e08c9960] scsi_wait_done+0x0/0x60 [scsi_mod]
 [e08a3462] sr_do_ioctl+0x92/0x2a0 [sr_mod]
 [e08a3155] sr_packet+0x25/0x40 [sr_mod]
 [e08e7a75] cdrom_get_disc_info+0x65/0xb0 [cdrom]
 [e08e372b] cdrom_mrw_exit+0x1b/0x70 [cdrom]
 [e08e3323] unregister_cdrom+0x83/0xb0 [cdrom]
 [e08a319a] sr_kref_release+0x2a/0x50 [sr_mod]
 [e08a3170] sr_kref_release+0x0/0x50 [sr_mod]
 [c01bf769] kref_put+0x39/0xa0
 [c01bed1f] kobject_put+0x1f/0x30
 [e08a31f9] sr_remove+0x39/0x4b [sr_mod]
 [e08a3170] sr_kref_release+0x0/0x50 [sr_mod]
 [c022e946] device_release_driver+0x86/0x90
 [c022ebc4] bus_remove_device+0x64/0xb0
 [c022d8cd] device_del+0x5d/0xa0
 [e08cda1f] scsi_remove_device+0x4f/0xb0 [scsi_mod]
 [e08ccaca] scsi_forget_host+0x2a/0x50 [scsi_mod]
 [e08c5319] scsi_remove_host+0x19/0x80 [scsi_mod]
 [e089e2dd] idescsi_cleanup+0x4d/0x60 [ide_scsi]
 [c024b95e] ide_unregister_driver+0x5e/0x90
 [c012f7f8] try_stop_module+0x28/0x30
 [e089edef] exit_idescsi_module+0xf/0x11 [ide_scsi]
 [c012f9b4] sys_delete_module+0x144/0x180
 [c0147500] do_munmap+0xf0/0x160
 [c01475b4] sys_munmap+0x44/0x70
 [c0102f33] syscall_call+0x7/0xb
Code: 8b 54 24 3c 8b 42 64 89 53 2c 89 43 14 89 43 0c 8b 4c 24 40 89 4b 30 a1 
a0 0d 35 c0 8b 72 3c 01 f0 89 43 38 8b 7c 24 24 8b 47 20 8b 80 e0 01 00 00 a8 
01 74 05 0f ba 6b 34 02 8b 43 1c 89 44 24 

-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgpRHRt4MHkWV.pgp
Description: PGP signature


Re: kernel BUG at fs/sysfs/symlink.c:87

2005-01-24 Thread Florian Lohoff
On Mon, Jan 24, 2005 at 04:51:00PM +0100, Florian Lohoff wrote:
> Hi,
> while using the bridging code between a tap0 and a real eth1 i got this:
> 
> Linux zmgr1.wstk.mediaways.net 2.6.10-zmgr-p3cel #1 Mon Jan 24 16:15:39 CET 
> 2005 i686 GNU/Linux
> 
> UP, P3 Celeron, Non-Preempt, Vanilla Kernel

brctl addbr br0
brctl addif br0 tap0
brctl addif br0 eth0
ifconfig br0 up

Oops

In this order it works

brctl addbr br0
ifconfig br0 up
brctl addif br0 tap0
brctl addif br0 eth0

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgp1OQ56aNSjO.pgp
Description: PGP signature


Re: kernel BUG at fs/sysfs/symlink.c:87

2005-01-24 Thread Florian Lohoff
On Mon, Jan 24, 2005 at 05:08:11PM +0100, Jörn Engel wrote:
> > Linux zmgr1.wstk.mediaways.net 2.6.10-zmgr-p3cel #1 Mon Jan 24 16:15:39 CET 
> > 2005 i686 GNU/Linux
> ^^
> Would be interesting to see if this shows up with a plain 2.6.10 as
> well.  Do you have time to check that?

Debian - make-kpkg --append-to-version=-zmgr-p3cel 

I am very shure this is vanilla - I compiled it myself just an hour ago.

> Looks like br_sysfs_addif() forgot to add a dentry to the kobj passed
> to sysfs_create_link(), but I'm not too familiar with that code.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgpNnW71xhTsP.pgp
Description: PGP signature


kernel BUG at fs/sysfs/symlink.c:87

2005-01-24 Thread Florian Lohoff

Hi,
while using the bridging code between a tap0 and a real eth1 i got this:

Linux zmgr1.wstk.mediaways.net 2.6.10-zmgr-p3cel #1 Mon Jan 24 16:15:39 CET 
2005 i686 GNU/Linux

UP, P3 Celeron, Non-Preempt, Vanilla Kernel

kernel BUG at fs/sysfs/symlink.c:87!
invalid operand:  [#1]
Modules linked in: ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc 
3c59x bridge tun autofs eepro100 e100 mii i2c_i801 i2c_core uhci_hcd usbcore
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.10-zmgr-p3cel)
EIP is at sysfs_create_link+0x56/0x60
eax: c45ef738   ebx:    ecx: c709f000   edx: c39b3ec0
esi: c8880878   edi: c7915728   ebp: c79156a0   esp: c4d91e94
ds: 007b   es: 007b   ss: 0068
Process brctl (pid: 3500, threadinfo=c4d9 task=c52b25e0)
Stack: c017b8cf c68ba7e4 c8880824  c887aa57 c45ef738 c7915728 c709f000
   c45ef220 c709f000 c79156a0 c45ef220  c887762d c79156a0 c79156a0
   c709f090 0001 c709f000 c45ef220 ffed c4d91f34 c8877c34 c45ef220
Call Trace:
 [] sysfs_create_file+0x2f/0x50
 [] br_sysfs_addif+0xe7/0x140 [bridge]
 [] br_add_if+0xbd/0x160 [bridge]
 [] add_del_if+0x64/0x80 [bridge]
 [] dev_ifsioc+0x384/0x3f0
 [] dev_ioctl+0x1e7/0x260
 [] inet_ioctl+0x9c/0xb0
 [] sock_ioctl+0xc9/0x240
 [] sys_ioctl+0xc9/0x240
 [] syscall_call+0x7/0xb
Code: 4c 24 04 8b 44 24 18 89 1c 24 89 44 24 08 e8 f2 fe ff ff 89 c1 8b 53 08 
ff 42 68 0f 8e 0b 02 00 00 8b 5c 24 0c 89 c8 83 c4 10 c3 <0f> 0b 57 00 f5 59 2c 
c0 eb be 8b 44 24 04 8b 40 30 89 44 24 04
 <7>tap0: no IPv6 routers present



Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgpAyriBLhf6U.pgp
Description: PGP signature


kernel BUG at fs/sysfs/symlink.c:87

2005-01-24 Thread Florian Lohoff

Hi,
while using the bridging code between a tap0 and a real eth1 i got this:

Linux zmgr1.wstk.mediaways.net 2.6.10-zmgr-p3cel #1 Mon Jan 24 16:15:39 CET 
2005 i686 GNU/Linux

UP, P3 Celeron, Non-Preempt, Vanilla Kernel

kernel BUG at fs/sysfs/symlink.c:87!
invalid operand:  [#1]
Modules linked in: ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc 
3c59x bridge tun autofs eepro100 e100 mii i2c_i801 i2c_core uhci_hcd usbcore
CPU:0
EIP:0060:[c017cac6]Not tainted VLI
EFLAGS: 00010246   (2.6.10-zmgr-p3cel)
EIP is at sysfs_create_link+0x56/0x60
eax: c45ef738   ebx:    ecx: c709f000   edx: c39b3ec0
esi: c8880878   edi: c7915728   ebp: c79156a0   esp: c4d91e94
ds: 007b   es: 007b   ss: 0068
Process brctl (pid: 3500, threadinfo=c4d9 task=c52b25e0)
Stack: c017b8cf c68ba7e4 c8880824  c887aa57 c45ef738 c7915728 c709f000
   c45ef220 c709f000 c79156a0 c45ef220  c887762d c79156a0 c79156a0
   c709f090 0001 c709f000 c45ef220 ffed c4d91f34 c8877c34 c45ef220
Call Trace:
 [c017b8cf] sysfs_create_file+0x2f/0x50
 [c887aa57] br_sysfs_addif+0xe7/0x140 [bridge]
 [c887762d] br_add_if+0xbd/0x160 [bridge]
 [c8877c34] add_del_if+0x64/0x80 [bridge]
 [c022d564] dev_ifsioc+0x384/0x3f0
 [c022d7b7] dev_ioctl+0x1e7/0x260
 [c0269d2c] inet_ioctl+0x9c/0xb0
 [c02231c9] sock_ioctl+0xc9/0x240
 [c015bc79] sys_ioctl+0xc9/0x240
 [c01024a3] syscall_call+0x7/0xb
Code: 4c 24 04 8b 44 24 18 89 1c 24 89 44 24 08 e8 f2 fe ff ff 89 c1 8b 53 08 
ff 42 68 0f 8e 0b 02 00 00 8b 5c 24 0c 89 c8 83 c4 10 c3 0f 0b 57 00 f5 59 2c 
c0 eb be 8b 44 24 04 8b 40 30 89 44 24 04
 7tap0: no IPv6 routers present



Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgpAyriBLhf6U.pgp
Description: PGP signature


Re: kernel BUG at fs/sysfs/symlink.c:87

2005-01-24 Thread Florian Lohoff
On Mon, Jan 24, 2005 at 05:08:11PM +0100, Jörn Engel wrote:
  Linux zmgr1.wstk.mediaways.net 2.6.10-zmgr-p3cel #1 Mon Jan 24 16:15:39 CET 
  2005 i686 GNU/Linux
 ^^
 Would be interesting to see if this shows up with a plain 2.6.10 as
 well.  Do you have time to check that?

Debian - make-kpkg --append-to-version=-zmgr-p3cel 

I am very shure this is vanilla - I compiled it myself just an hour ago.

 Looks like br_sysfs_addif() forgot to add a dentry to the kobj passed
 to sysfs_create_link(), but I'm not too familiar with that code.

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgpNnW71xhTsP.pgp
Description: PGP signature


Re: kernel BUG at fs/sysfs/symlink.c:87

2005-01-24 Thread Florian Lohoff
On Mon, Jan 24, 2005 at 04:51:00PM +0100, Florian Lohoff wrote:
 Hi,
 while using the bridging code between a tap0 and a real eth1 i got this:
 
 Linux zmgr1.wstk.mediaways.net 2.6.10-zmgr-p3cel #1 Mon Jan 24 16:15:39 CET 
 2005 i686 GNU/Linux
 
 UP, P3 Celeron, Non-Preempt, Vanilla Kernel

brctl addbr br0
brctl addif br0 tap0
brctl addif br0 eth0
ifconfig br0 up

Oops

In this order it works

brctl addbr br0
ifconfig br0 up
brctl addif br0 tap0
brctl addif br0 eth0

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Heisenberg may have been here.


pgp1OQ56aNSjO.pgp
Description: PGP signature


Re: Oops in iput

2001-06-26 Thread Florian Lohoff

On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote:
> Well, I for one use the 2.2 ide patches extensively (on almost all of my
> machines, including a heavy-duty backup server), and haven't seen any
> problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for
> example.

I have been using the udma ide patches for a long time and as long as
you stay away from known buggy drives controllers you are fine.

BTW: The machine i reported the bug for is mostly running on SCSI - Only
/var/tmp is an large IDE drive.
 
> I don't mean to say the ide patches are 100% bug free, but I wouldn't
> consider them as the prime suspect for an oops that happened elsewhere
> either. It could be hw or any other part of kernel just as well... What
> about memtest86?

I'll try 

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

-
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: Oops in iput

2001-06-26 Thread Florian Lohoff

On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote:
 Well, I for one use the 2.2 ide patches extensively (on almost all of my
 machines, including a heavy-duty backup server), and haven't seen any
 problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for
 example.

I have been using the udma ide patches for a long time and as long as
you stay away from known buggy drives controllers you are fine.

BTW: The machine i reported the bug for is mostly running on SCSI - Only
/var/tmp is an large IDE drive.
 
 I don't mean to say the ide patches are 100% bug free, but I wouldn't
 consider them as the prime suspect for an oops that happened elsewhere
 either. It could be hw or any other part of kernel just as well... What
 about memtest86?

I'll try 

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called common sense when nobody seems to have any?

-
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/



Oops in iput

2001-06-25 Thread Florian Lohoff


Hi,
oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)

Intel BX chipset, SCSI Disks Symbios chipset - The crashing process
is the master process of "postfix" an MTA.

Just before the crash all processes on that machine started to segfault
in nameserver resolution (remote dns server) and after 2-3 minutes
this oops happened.



ksymoops 2.3.4 on i686 2.2.19.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.19/ (default)
 -m /boot/System.map-2.2.19 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Unable to handle kernel paging request at virtual address 4ed90398
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 4ed90330   ebx:    ecx:    edx: c01eef0c
esi: 4ed90330   edi: ce27ed00   ebp: 0002   esp: cf04ddac
ds: 0018   es: 0018   ss: 0018
Process master (pid: 297, process nr: 31, stackpage=cf04d000)
Stack: cf1859a0 0001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330  
   ce27ec80 0002 ced90330 ced90330 ce27ed00 0002 ceadc0c0  
   cfce5860 c0158be3 ced903e0 ceeda140  0002 ceeda140 ced90330 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] 
Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 

>>EIP; c0133ca7<=
Trace; c015882f 
Trace; c0158be3 
Trace; c011b26c 
Trace; c01262bd <__fput+25/54>
Trace; c011d2b5 
Trace; c012745c 
Trace; c0127453 
Trace; c01139bb 
Trace; c012634b 
Trace; c011073e 
Trace; c0113958 
Trace; c01184f4 
Trace; c011847d 
Trace; c0109fbb 
Trace; c0b1 
Trace; c0109583 
Trace; c010a100 
Code;  c0133ca7 
 <_EIP>:
Code;  c0133ca7<=
   0:   8b 46 68  mov0x68(%esi),%eax   <=
Code;  c0133caa 
   3:   85 c0 test   %eax,%eax
Code;  c0133cac 
   5:   74 09 je 10 <_EIP+0x10> c0133cb7 
Code;  c0133cae 
   7:   8b 40 18  mov0x18(%eax),%eax
Code;  c0133cb1 
   a:   85 c0 test   %eax,%eax
Code;  c0133cb3 
   c:   74 02 je 10 <_EIP+0x10> c0133cb7 
Code;  c0133cb5 
   e:   89 c3 mov%eax,%ebx
Code;  c0133cb7 
  10:   85 db test   %ebx,%ebx
Code;  c0133cb9 
  12:   74 10 je 24 <_EIP+0x24> c0133ccb 


1 warning issued.  Results may not be reliable.
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

-
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/



Oops in iput

2001-06-25 Thread Florian Lohoff


Hi,
oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)

Intel BX chipset, SCSI Disks Symbios chipset - The crashing process
is the master process of postfix an MTA.

Just before the crash all processes on that machine started to segfault
in nameserver resolution (remote dns server) and after 2-3 minutes
this oops happened.



ksymoops 2.3.4 on i686 2.2.19.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.19/ (default)
 -m /boot/System.map-2.2.19 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Unable to handle kernel paging request at virtual address 4ed90398
current-tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[c0133ca7]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 4ed90330   ebx:    ecx:    edx: c01eef0c
esi: 4ed90330   edi: ce27ed00   ebp: 0002   esp: cf04ddac
ds: 0018   es: 0018   ss: 0018
Process master (pid: 297, process nr: 31, stackpage=cf04d000)
Stack: cf1859a0 0001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330  
   ce27ec80 0002 ced90330 ced90330 ce27ed00 0002 ceadc0c0  
   cfce5860 c0158be3 ced903e0 ceeda140  0002 ceeda140 ced90330 
Call Trace: [c015882f] [c0158be3] [c011b26c] [c01262bd] [c011d2b5] 
[c012745c] [c0127453] 
   [c01139bb] [c012634b] [c011073e] [c0113958] [c01184f4] [c011847d] 
[c0109fbb] [c0b1] 
   [c0109583] [c010a100] 
Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 

EIP; c0133ca7 iput+13/228   =
Trace; c015882f sock_release+57/60
Trace; c0158be3 sock_close+3f/4c
Trace; c011b26c clear_page_tables+ac/b4
Trace; c01262bd __fput+25/54
Trace; c011d2b5 exit_mmap+115/120
Trace; c012745c fput+20/54
Trace; c0127453 fput+17/54
Trace; c01139bb mmput+3f/48
Trace; c012634b filp_close+5f/6c
Trace; c011073e send_sig_info+182/2c0
Trace; c0113958 mm_release+10/34
Trace; c01184f4 do_exit+140/2a0
Trace; c011847d do_exit+c9/2a0
Trace; c0109fbb do_signal+21f/298
Trace; c0b1 sys_kill+61/70
Trace; c0109583 sys_sigreturn+b7/e8
Trace; c010a100 signal_return+14/18
Code;  c0133ca7 iput+13/228
 _EIP:
Code;  c0133ca7 iput+13/228   =
   0:   8b 46 68  mov0x68(%esi),%eax   =
Code;  c0133caa iput+16/228
   3:   85 c0 test   %eax,%eax
Code;  c0133cac iput+18/228
   5:   74 09 je 10 _EIP+0x10 c0133cb7 iput+23/228
Code;  c0133cae iput+1a/228
   7:   8b 40 18  mov0x18(%eax),%eax
Code;  c0133cb1 iput+1d/228
   a:   85 c0 test   %eax,%eax
Code;  c0133cb3 iput+1f/228
   c:   74 02 je 10 _EIP+0x10 c0133cb7 iput+23/228
Code;  c0133cb5 iput+21/228
   e:   89 c3 mov%eax,%ebx
Code;  c0133cb7 iput+23/228
  10:   85 db test   %ebx,%ebx
Code;  c0133cb9 iput+25/228
  12:   74 10 je 24 _EIP+0x24 c0133ccb iput+37/228


1 warning issued.  Results may not be reliable.
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called common sense when nobody seems to have any?

-
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/



Serial console != baud 9k6

2001-01-29 Thread Florian Lohoff

Hi,
i am just working on a different arch (mips board) and try to initialize
the serial console from the arch specific setup with
setup_console("ttyS0,57600") which doesnt work it seems as
serial_console_setup is itself "__init" and has a default of 9k6.

So how do i init the serial console from the arch specific stuff with
something else than the default baud rate ?

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Serial console != baud 9k6

2001-01-29 Thread Florian Lohoff

Hi,
i am just working on a different arch (mips board) and try to initialize
the serial console from the arch specific setup with
setup_console("ttyS0,57600") which doesnt work it seems as
serial_console_setup is itself "__init" and has a default of 9k6.

So how do i init the serial console from the arch specific stuff with
something else than the default baud rate ?

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [Linux-IrDA]Re: [IrDA+SMP] Lockup in handle_IRQ_event

2001-01-04 Thread Florian Lohoff

On Thu, Jan 04, 2001 at 10:18:46AM +1100, Andrew Morton wrote:
> Marc ZYNGIER wrote:
> > 
> > Hi all,
> > 
> > Having just started playing with IrDA on my dual celeron (Abit "APIC
> > error..." BP6), I managed to kill it every single time (NMI watchdog
> > in handle_IRQ_event) while connecting to my mobile phone (in fact,
> > when closing the connection to the phone. even 'cat /dev/ircomm0' will
> > do...). This is perfectly repeatable.
> > 
> 
> Try this:
> 
> --- linux-2.4.0-prerelease/net/irda/irqueue.c Tue Nov 21 20:11:22 2000
> +++ linux-akpm/net/irda/irqueue.c Thu Jan  4 10:14:10 2001
> @@ -436,7 +436,7 @@
>  
>   /* Release lock */
>   if ( hashbin->hb_type & HB_GLOBAL) {
> - spin_unlock_irq( >hb_mutex[ bin]);
> + spin_unlock_irqrestore( >hb_mutex[ bin], flags);
>  
>   } else if ( hashbin->hb_type & HB_LOCAL) {
>   restore_flags( flags);

BTW: What i have seen in the ircomm_tty.c (2.2.18):

647 save_flags(flags);
648 cli();
649 
650 skb = self->tx_skb;
651 self->tx_skb = NULL;
652 
653 restore_flags(flags);

and a lot of other places simply use "save_flags(flags); cli();
restore_flags()". Can someone enlighten me how this is supposed to work
on SMP machines ? AFAIK "cli()" only disables IRQs on the local
CPU so a different CPU could easily stumple half way as this
is definitly non atomic. Or is the tty layer protected by some
"big tty lock" ?

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [Linux-IrDA]Re: [IrDA+SMP] Lockup in handle_IRQ_event

2001-01-04 Thread Florian Lohoff

On Thu, Jan 04, 2001 at 10:18:46AM +1100, Andrew Morton wrote:
 Marc ZYNGIER wrote:
  
  Hi all,
  
  Having just started playing with IrDA on my dual celeron (Abit "APIC
  error..." BP6), I managed to kill it every single time (NMI watchdog
  in handle_IRQ_event) while connecting to my mobile phone (in fact,
  when closing the connection to the phone. even 'cat /dev/ircomm0' will
  do...). This is perfectly repeatable.
  
 
 Try this:
 
 --- linux-2.4.0-prerelease/net/irda/irqueue.c Tue Nov 21 20:11:22 2000
 +++ linux-akpm/net/irda/irqueue.c Thu Jan  4 10:14:10 2001
 @@ -436,7 +436,7 @@
  
   /* Release lock */
   if ( hashbin-hb_type  HB_GLOBAL) {
 - spin_unlock_irq( hashbin-hb_mutex[ bin]);
 + spin_unlock_irqrestore( hashbin-hb_mutex[ bin], flags);
  
   } else if ( hashbin-hb_type  HB_LOCAL) {
   restore_flags( flags);

BTW: What i have seen in the ircomm_tty.c (2.2.18):

647 save_flags(flags);
648 cli();
649 
650 skb = self-tx_skb;
651 self-tx_skb = NULL;
652 
653 restore_flags(flags);

and a lot of other places simply use "save_flags(flags); cli();
restore_flags()". Can someone enlighten me how this is supposed to work
on SMP machines ? AFAIK "cli()" only disables IRQs on the local
CPU so a different CPU could easily stumple half way as this
is definitly non atomic. Or is the tty layer protected by some
"big tty lock" ?

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



get_tty_baud_rate() on sparc64

2000-09-19 Thread Florian Lohoff

Hi,
while porting a serial multiport driver to sparc64 i disovered that the
function get_tty_baud_rate() only returns 50 or 75 Baud
for 57600 and 115200 which is *aehm* not what i expected.

Is this something i made wrong when setting up something or
is it another "Sparc[64] is different" issue ?

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED]  +49-5201-669912
  "Write only memory - Oops. Time for my medication again ..."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



get_tty_baud_rate() on sparc64

2000-09-19 Thread Florian Lohoff

Hi,
while porting a serial multiport driver to sparc64 i disovered that the
function get_tty_baud_rate() only returns 50 or 75 Baud
for 57600 and 115200 which is *aehm* not what i expected.

Is this something i made wrong when setting up something or
is it another "Sparc[64] is different" issue ?

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED]  +49-5201-669912
  "Write only memory - Oops. Time for my medication again ..."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



ioremap & Co i386 -> sparc64

2000-09-18 Thread Florian Lohoff

Hi,
i am currently in the process of porting my serial driver for
this board

02:03.0 Communication controller: PLX Technology, Inc. 9060SD (rev 02)
Subsystem: Aurora Technologies, Inc. Aries 16000P
Flags: medium devsel, IRQ 6063168
Memory at f9ff2000 (32-bit, non-prefetchable)
I/O ports at 2000400
Memory at f9ff4000 (32-bit, non-prefetchable)
Expansion ROM at 8000 [disabled]

to sparc64 - Basically the thing compiles but in the first
round i found a lot 32Bitisms for addresses which is *aehm* wrong.

But now it seems i am running into the beloved ioremap vs whatever
problem. I read IO-remap in the Documentation area and i think i did it
right but i get an 

data_access_exception: Shit SFSR[0088100d] SFAR[01ff4040], going.

Which is the reset routing trying to write a single byte with writeb.
Here the important parts ..

In the find_card i do this ..

[...]
cd1865_base=ioremap(pdev->base_address[2] &

PCI_BASE_ADDRESS_MEM_MASK,
AA_CHIP_PCI_SIZE);

While resetting the first writeb (ba contains cd1865_base) 

[...]
/* Set GSVR to 0x0 */
writeb(0x00, ba + CD1865_GSVR);

This is all Kernel 2.2.17

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED]  +49-5201-669912
  "Write only memory - Oops. Time for my medication again ..."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



ioremap Co i386 - sparc64

2000-09-18 Thread Florian Lohoff

Hi,
i am currently in the process of porting my serial driver for
this board

02:03.0 Communication controller: PLX Technology, Inc. 9060SD (rev 02)
Subsystem: Aurora Technologies, Inc. Aries 16000P
Flags: medium devsel, IRQ 6063168
Memory at f9ff2000 (32-bit, non-prefetchable)
I/O ports at 2000400
Memory at f9ff4000 (32-bit, non-prefetchable)
Expansion ROM at 8000 [disabled]

to sparc64 - Basically the thing compiles but in the first
round i found a lot 32Bitisms for addresses which is *aehm* wrong.

But now it seems i am running into the beloved ioremap vs whatever
problem. I read IO-remap in the Documentation area and i think i did it
right but i get an 

data_access_exception: Shit SFSR[0088100d] SFAR[01ff4040], going.

Which is the reset routing trying to write a single byte with writeb.
Here the important parts ..

In the find_card i do this ..

[...]
cd1865_base=ioremap(pdev-base_address[2] 

PCI_BASE_ADDRESS_MEM_MASK,
AA_CHIP_PCI_SIZE);

While resetting the first writeb (ba contains cd1865_base) 

[...]
/* Set GSVR to 0x0 */
writeb(0x00, ba + CD1865_GSVR);

This is all Kernel 2.2.17

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED]  +49-5201-669912
  "Write only memory - Oops. Time for my medication again ..."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.2.17 doesnt build on sparc64 with CONFIG_IP_PNP

2000-09-15 Thread Florian Lohoff


Hi,
current 2.2.17 sparc64 kernel doesnt build with CONFIG_IP_PNP
enabled

make[2]: Entering directory `/usr/src/linux/arch/sparc64/kernel'
sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -m64 -pipe -mno-fpu -mcpu=ultrasparc 
-mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare   -c -o 
setup.o setup.c
setup.c: In function `setup_arch':
setup.c:553: `ic_set_manually' undeclared (first use in this function)
setup.c:553: (Each undeclared identifier is reported only once
setup.c:553: for each function it appears in.)
make[2]: *** [setup.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/sparc64/kernel'
make[1]: *** [_dir_arch/sparc64/kernel] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [stamp-build] Error 2


Flo
-- 
Florian Lohoff  [EMAIL PROTECTED]  +49-5201-669912
  "Write only memory - Oops. Time for my medication again ..."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.2.17 doesnt build on sparc64 with CONFIG_IP_PNP

2000-09-15 Thread Florian Lohoff


Hi,
current 2.2.17 sparc64 kernel doesnt build with CONFIG_IP_PNP
enabled

make[2]: Entering directory `/usr/src/linux/arch/sparc64/kernel'
sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -m64 -pipe -mno-fpu -mcpu=ultrasparc 
-mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare   -c -o 
setup.o setup.c
setup.c: In function `setup_arch':
setup.c:553: `ic_set_manually' undeclared (first use in this function)
setup.c:553: (Each undeclared identifier is reported only once
setup.c:553: for each function it appears in.)
make[2]: *** [setup.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/sparc64/kernel'
make[1]: *** [_dir_arch/sparc64/kernel] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [stamp-build] Error 2


Flo
-- 
Florian Lohoff  [EMAIL PROTECTED]  +49-5201-669912
  "Write only memory - Oops. Time for my medication again ..."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/