https://bugzilla.novell.com/show_bug.cgi?id=433936
User awafaa(a)opensuse.org added comment
https://bugzilla.novell.com/show_bug.cgi?id=433936#c1
Summary: Issues Symbian OS 9.1 powered mobile phones
Product: openSUSE 11.0
Version: Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: awafaa(a)opensuse.org
QAContact: qa(a)suse.de
Found By: ---
ll three
of my Symbian powered phones seem to have issues with openSUSE. I have
one SonyEricsson M600i, one Nokia N95 and one Nokia E71; all three of
them show the same issues.
When I connect the phone* to either my 11.0 or 11.1 machine I get the
following in /var/log/messages:
Oct 9 10:59:27 fveult05 kernel: hub 2-0:1.0: unable to enumerate USB
device on port 4
Oct 9 10:59:27 fveult05 kernel: usb 3-2: new full
speed USB device using uhci_hcd and address 2
Oct 9 10:59:28 fveult05 kernel: usb 3-2: configuration #1 chosen from
1 choice
Oct 9 10:59:28 fveult05 kernel: usb 3-2: New USB device found,
idVendor=0421, idProduct=00ab
Oct 9 10:59:28 fveult05 kernel: usb 3-2: New USB device strings:
Mfr=1, Product=2, SerialNumber=0
Oct 9 10:59:28 fveult05 kernel: usb 3-2: Product: Nokia E71
Oct 9 10:59:28 fveult05 kernel: usb 3-2: Manufacturer: Nokia
Oct 9 10:59:29 fveult05 kernel: cdc_acm 3-2:1.10: ttyACM0: USB ACM
device
Oct 9 10:59:29 fveult05 kernel: usbcore: registered new interface
driver cdc_acm
Oct 9 10:59:29 fveult05 kernel:drivers/usb/class/cdc-acm.c: v0.25:USB
Abstract Control Model driver for USB modems and ISDN adapters
Oct 9 10:59:29 fveult05 kernel: usbcore: registered new interface
driver cdc_ether
Oct 9 10:59:29 fveult05 kernel: usb 3-2: bad CDC descriptors
Oct 9 10:59:29 fveult05 kernel: usbcore: registered new interface
driver rndis_host
Oct 9 10:59:29 fveult05 kernel: usb 3-2: bad CDC descriptors
Oct 9 10:59:29 fveult05 kernel: usbcore: registered new interface
driver rndis_wlan
If I look at dmesg it shows pretty much the same (funnily enough):
hub 2-0:1.0: unable to enumerate USB device on port 4
usb 3-2: new full speed USB device using uhci_hcd and address 2
usb 3-2: configuration #1 chosen from 1 choice
usb 3-2: New USB device found, idVendor=0421, idProduct=00ab
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-2: Product: Nokia E71
usb 3-2: Manufacturer: Nokia
cdc_acm 3-2:1.10: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver
for USB modems and ISDN adapters usbcore: registered new interface
driver cdc_ether usb 3-2: bad CDC descriptors
usbcore: registered new interface driver rndis_host
usb 3-2: bad CDC descriptors
usbcore: registered new interface driver rndis_wlan
The issue with this is that I am unable to use my phone as a USB modem
in conjunction with NetworkManager, either in KDE or GNOME. Is there
anything that can be done, and is it worth filing a bug? As Nokia use
Symbian pretty much exclusively to power their handsets and they have
40% of the market globally I personally would like to see us support
their use :)
I think this could well be an upstream issue as I tried to connect the
phones to a ForesightLinux machine with pretty much the same issues.
*These were taken from connecting my E71, but the output is almost
identical with the others.
If the phones are used in the "Mass Storage" mode, then there are no issues and
I can browse the phones as if they were USB keys.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=445878
Summary: Separate better step done with actual job remaining
during setup
Product: openSUSE 11.1
Version: Beta 5
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: Installation
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: romain.pelissier(a)gmail.com
QAContact: jsrain(a)novell.com
Found By: ---
I have noticed that during the setup at the end of the installation there are a
smal part about the configuration of the user printer.
In my case, I do not have a printer so the page displayed juste says Printer
Setup or something like that with some text below like 'Finish printer
configuration'
The issue that that the progress bar at the botom still show that some stuff
are being downloaded and installed.
Could a clean page be added after the printer setup to not confused the user so
download and installed all parts needed at the end of the hardware setup?
No bug issue but could improve the setup experience.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=389386
User mmrazik(a)novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=389386#c358865
Summary: vnc installation crashes
Product: openSUSE 11.0
Version: Beta 2
Platform: Other
OS/Version: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: YaST2
AssignedTo: sndirsch(a)novell.com
ReportedBy: mmrazik(a)novell.com
QAContact: jsrain(a)novell.com
Found By: ---
Created an attachment (id=214455)
--> (https://bugzilla.novell.com/attachment.cgi?id=214455)
y2logs
This might be a duplicate of bug #358865 but I'm observing this on a i386
machine (it is a x86_64 host with i386 installation).
VNC installation crashes right after connection of the VNC client. The VNC
client is asked for a password and right after the password is entered the
installation crashes with "An error occurred during the installation" message.
y2logs attached. Unfortunately I don't know how to debug this better so if you
need more logs please let me know. I think this one may be easy to reproduce.
Attached are 2 screenshots from the text console (from KVM). This host doesn't
have serial port thus I'm unable to attach the whole output.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=370872
Summary: "pccardctl eject" hangs in state D
Product: openSUSE 11.0
Version: Alpha 2plus
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
AssignedTo: kernel-maintainers(a)forge.provo.novell.com
ReportedBy: seife(a)novell.com
QAContact: qa(a)suse.de
CC: fseidel(a)novell.com
Found By: Development
During suspend, one thing we do is eject PCMCIA card with "pccardctl eject".
I quite frequently see that command hanging in state D, which makes suspend
fail. Attempting to shut down the machine cleanly lead to a hang when the sound
modules are unloaded, a clean shutdown does only happen if i do a sysrq-e to
kill the hanging processes and make init proceed.
I have seen this with various 3G/UMTS CardBus cards, both USB-serial based and
nozomi based, so i believe this to be a generic PCMCIA issue.
Will attach sysrq-T
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=362947
Summary: evaluate debian/ubuntu libtool patch
Product: openSUSE 11.0
Version: Alpha 2
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: Development
AssignedTo: schwab(a)novell.com
ReportedBy: crrodriguez(a)novell.com
QAContact: qa(a)suse.de
Found By: Development
Both debian and Ubuntu are using a libtool patch{1} that sets
link_all_deplibs=no on ELF systems, this will help a lot reducing unedded
library dependencies in packages.
{1}
http://patches.ubuntu.com/by-release/extracted/debian/libt/libtool/1.5.26-1…
This is just a suggestion, I think this may work for us as well ( ubuntu and
debian archives are a biiiigg test ;) )
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=413904
Summary: Ricoh MMC card reader doesn't function
Product: openSUSE 11.0
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.0
Status: NEW
Severity: Major
Priority: P5 - None
Component: Hotplug
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: jos.baudrez(a)telenet.be
QAContact: qa(a)suse.de
Found By: ---
When an SD card gets inserted in the slot on my Thinkpad x61s, I do not get any
response; fdisk -l doesn't see anything in there and the var/log/messages file
says:
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci: SDHCI controller found at 0000:05:00.2 [1180:0822] (rev 21)
ACPI: PCI Interrupt 0000:05:00.2[C] -> GSI 18 (level, low) -> IRQ 18
sdhc0:slot0: Will use DMA mode even though HW doesn't fully claim to support
it.
PCI: Setting latency timer of device 0000:05:00.2 to 64
mmc0: SDHCI at 0xf8301800 irq 18 DMA
mmc0: new high speed SD card at address b368
mmcblk0: mmc0:b368 SD 1997312KiB
mmcblk0:<3>mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
printk: 3 messages suppressed.
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
ldm_validate_partition_table(): Disk read failed.
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 24
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
unable to read partition table
mmcblk0: error -84 transferring data
end_request: I/O error, dev mmcblk0, sector 0
end_request: I/O error, dev mmcblk0, sector 8
end_request: I/O error, dev mmcblk0, sector 16
end_request: I/O error, dev mmcblk0, sector 24
I have been told this is a 'new' bug, so i start a new thread.
If i can be of any further use pls. let me know!
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=442475
Summary: The Cancel and Skip Refresh still does Not Operate with
a Higher Priory than the Yast Application Itself
Product: openSUSE 11.0
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.0
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: YaST2
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: alpha096(a)virginbroadband.com.au
QAContact: jsrain(a)novell.com
Found By: Customer
If a Yast Application stalls at any point, using the Cancel Button has NO
effect on the Yast Application. There needs to have both Cancel and Skip
Refresh and Abort buttons operate with a much higher Priority that the Yast
Application itself.
Using the 'Skip Refresh' button certainly does work most of the time but not
100% of the time - Its Priority still needs to be higher.
The cancel or Abort buttons - never close or stop a misbehaving Yast
Application or abouts the saving of a Yast Application and is essentially
useless.
Both Abort, Cancel and Skip Refresh, all need to operate with the Highest CPU
authority or always higher than the Yast Application itself.
We have taken for granted that both cancel or Abort buttons never function
after we commit to any changes via a Yast Application Window and perhaps it is
long overdue for us to correct this
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=341350
Summary: severe limitations in xen-tools python scripts
Product: openSUSE 10.3
Version: Final
Platform: x86-64
OS/Version: openSUSE 10.3
Status: NEW
Severity: Major
Priority: P5 - None
Component: Xen
AssignedTo: cgriffin(a)novell.com
ReportedBy: duwe(a)novell.com
QAContact: qa(a)suse.de
Found By: Development
qemu-dm appears to be accepting the same type of arguments as qemu does;
however the automatically generated command line is impossible to contain
1st) multiple "-usbdevice" switches --
one is already used up by the "tablet" option.
2nd) a "-parallel" switch
This may not be serious for a server virtualisation, but it surely hurts on the
desktop.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343180
Summary: XEN keymap problem.
Product: openSUSE 10.3
Version: Final
Platform: i586
OS/Version: openSUSE 10.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Xen
AssignedTo: cgriffin(a)novell.com
ReportedBy: nice(a)titanic.nyme.hu
QAContact: qa(a)suse.de
Found By: Other
I installed Vindows Vista on Xen by vm-install ran from YaST with the following
settings (/etc/xen/vm/windowsvista):
###############################################
name="windowsvista"
ostype="windowsvista"
uuid="cf93a3e0-c33f-50c4-dd3f-b68691418a40"
memory=1024
vcpus=1
on_crash="destroy"
on_poweroff="destroy"
on_reboot="restart"
localtime=1
builder="hvm"
extid=0
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="c"
disk=[ 'file:/mnt/xen/vista.bin,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r', ]
vif=[ 'mac=00:16:3e:1a:4d:7d,model=rtl8139,type=ioemu', ]
stdvga=0
vnc=1
vncunused=1
apic=0
acpi=1
pae=1
usb=1
usbdevice='tablet'
serial="pty"
###############################################
I tried to manage this qemu-dm assisted fully virtualized host either via VNC
or SDL (changing the config file above), but I realized that the host's
keyboard map was incomplete and incorrect. Let's see a sort example from the
file /var/log/xen qemu-dm.29632.log:
###############################################
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 501
Warning: no scancode found for keysym 501
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
Warning: no scancode found for keysym 507
###############################################
I figured out that the problem could by corrected by make qemu-dm use some of
the keymaps under /usr/share/xen/qemu/keymaps by passing a -key CODE parameter
to it. Or am I wrong? I also figured out that I can make xend to pass this
parameter to qemu-dm by adding a keymap='CODE' line to the /etc/xen/vm/VM file.
So I added the line keymap='hu' to the vm config file, and qemu-vm's command
line really changed:
milleniumfalcon:/var/log/xen # cat /proc/8046/cmdline | sed y/'\x0'/' '/
/usr/lib/xen/bin/qemu-dm -d 2 -vcpus 1 -boot c -localtime -serial pty -acpi
-usb -usbdevice tablet -k hu -domain-name windowsvista -net
nic,vlan=1,macaddr=00:16:3e:1a:4d:7d,model=rtl8139 -net tap,vlan=1 -vncunused
-vnclisten 127.0.0.1 milleniumfalcon:/var/log/xen # cat /proc/8046/cmdline |
sed y/'\x0'/' '/
The keyboard got a bit better but there are still missing keys, "ű" for
example. I tried other keymaps with similar results. What may be wrong with
these keymaps? Are they defectivein a way? I have no idea.
Thist bug report is primarily about the possible errors int these keymap files,
but I have other related quetions too:
It wold be good to make it possible to change the keymap setting in vm-install
if it is necessary at all.
Furthermore I do not know where virt-manager gets the information about VMs
from. Once I moved every file from /etc/xen/vm to the root directory, restarted
virt-manager and in spite of the lack of VM description files it still
remebered my guest VM.
I also do not know, what keeps the files /etc/xen/vm/VM and /etc/xen/vm/VM.xml
in synchron.
So, if i add a keymap to the file /etc/xen/vm/VM then that VM will use that
keymap if I start if by the xm command. But what happens if i start that VM
from virt-manager? Do I also need to add the keymap to the file
/etc/xen/vm/VM.xml? Or to a third file?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.