Latest Bugs & Tasks
Haiku always crashes on boot with HP LaserJet 1102w printer attached.
Probably because the printer emulates usb drive with windows driver.
When plugged after boot this is what I get in syslog:
KERN: usb hub 7: port 3: new device connected KERN: usb_disk: device reports a lun count of 1 KERN: usb_disk: vendor_identification "HP " KERN: usb_disk: product_identification "Smart Install " KERN: usb_disk: product_revision_level "1.0 " KERN: usb error ehci -1: qtd (0x571fd00) error: 0x00088d40 KERN: usb_disk: operation 0x25 failed at the SCSI level KERN: usb_disk: failed to update capacity: Device media changed
046d:c062 /dev/bus/usb/0/1 "Logitech, Inc." "M-UAS144 [LS1 Laser Mouse]" ver. 3100 046d:c315 /dev/bus/usb/0/2 "Logitech, Inc." "Classic Keyboard 200" ver. 2800 0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "OHCI RootHub" ver. 0110 03f0:102a /dev/bus/usb/1/3 "Hewlett-Packard" "HP LaserJet Professional P 1102w" ver. 0100 0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "EHCI RootHub" ver. 0200
listusb -v /dev/bus/usb/1/3
[Device /dev/bus/usb/1/3] Class .................. 0x00 (Per-interface classes) Subclass ............... 0x00 Protocol ............... 0x00 Max Endpoint 0 Packet .. 64 USB Version ............ 0x0200 Vendor ID .............. 0x03f0 (Hewlett-Packard) Product ID ............. 0x102a Product Version ........ 0x0100 Manufacturer String .... "Hewlett-Packard" Product String ......... "HP LaserJet Professional P 1102w" Serial Number .......... "000000000W412KEASI1c" [Configuration 0] Configuration String . "" [Interface 0] [Alternate 0 active] Class .............. 0x08 (Mass storage) Subclass ........... 0x06 Protocol ........... 0x50 Interface String ... "HP MS" [Endpoint 0] MaxPacketSize .... 512 Interval ......... 0 Type ............. Bulk Direction ........ Output [Endpoint 1] MaxPacketSize .... 512 Interval ......... 0 Type ............. Bulk Direction ........ Input
On lastest Haiku build (official nightly hrev49559 x86 hybrid gcc2) downloaded 21 august 2015, I still have the same speed issue.
I launch an sftp transfer of a file from haiku virtual host to physical host RHEL (Redhat Enterprise Linux) 6.5.
Then I launch an sftp transfer of the same file from ubuntu mate 15.04 32 bits to the same physical host RHEL (Redhat Enterprise Linux) 6.5.
Haiku and ubuntu are installed on the same virtualbox binaries (Virtualbox 4.3.14 hrev95030 provided with RHEL 6.5).
And with the same virtual network configuration (NAT Intel PRO/1000 MT Desktop (82540EM)).
The RHEL openssh server is openssh-server-5.3p1-94.el6.x86_64
ubuntu openssh version: OpenSSH_6.9p1, OpenSSL 1.0.0s 11 Jun 2015
haiku openssh version: OpenSSH_6.9p1, OpenSSL 1.0.0s 11 Jun 2015
On ubuntu the average speed is 35 MB/s.
On haiku the average speed is 8.8 MB/s.
Joined 2 screenshot and haiku /var/log/syslog + /var/log/syslog.old + versions of openssh.
Replying to ttcoder:
Discussion (to continue in a new /clean ticket maybe):
- wouldn't it be better if the kernel "held tight" on the crashed thread, instead of letting it go ?
That presents its own problems, since in the case where something goes wrong, that leaves you with a permanently unkillable thread without a reboot.
- if it isn't, how could Debugger give a hint about what happened ? Seeing a list of threads with no indication of any of them being stopped gives the (false) impression that the Debugger report is spurious and the team did not really crash. We probably don't want that.
All the Debugger knows is the kernel told it the thread exited, so there's no way for it to differentiate that. That having been said, to be perfectly blunt, the attached code sample is pretty much a case study in how not to do things.
- kill_thread() should never be getting used as a matter of course by application code, it exists as a last resort, and only that, since among other things, any resources the thread may have allocated would have been leaked in such a case, i.e. any memory/objects/sockets allocated by ntp_update_time(), and in fact, could potentially even cause issues/corruption for future invocations within the same team. kill_thread() exists solely for the use of tools like kill or ProcessController. Furthermore, since Haiku is currently single user, any mistake can potentially result in it killing threads in other teams, leading to other unpredictable behavior.
- The way UpdateSystemTime() currently works is pretty horribly broken, as it will result in the aforementioned condition getting triggered if there's any transient network lag or temporary loss in connectivity, and as such, if this is being run periodically will cause the hosting application to leak resources over time, eventually leading to other code randomly failing.
- Last but not least, loading an image as an add-on that isn't designed to be, such as an application image, is asking for trouble. That will cause global constructors/destructors to be called, which, if there are global and/or static variables involved, could potentially mess with the internal state of the calling application. Since all the source code in question is available, if you really want to use it this way, it would make more sense to simply pull that code into your own function and call it directly rather than the series of messy kludges used here. Alternatively, submitting a patch that pulls the ntp functionality into a daemon/standalone app that could be invoked by others would also be nice.
All in all, you're pretty much causing your own problems here in many ways, and I really don't see any good reason to go out of the way to accommodate such a situation.
HaikuDepot aligns rating stars to the left on package click in featured view if it gets rating info from HDS.
Somehow the patch did not apply anymore, and I noticed that there were no checks for packageRef.Get() != NULL. So I quickly re-implemented it based on your patch. Thanks! Fixed in hrev49557.
This is hrev49523
We load Time as an add-on into CC's address space to use the Network Time Protocol syncing feature within it, about every 3 minutes (basically after each transition from one song to the next). Seems to work great initially.
However I Just saw this for the first time after doing an extended 12+ hr test run since the past night (and we had reports hinting at this for a few weeks in older hrevs).
All splitviews in Debugger were collapsed and 'locked' (I thought I had deleted the settings in config/settings/Debugger but will try again before filing a ticket for that) but retrieving the info from syslog was easy:
KERN: vm_soft_fault: va 0x719a0000 not covered by area in address space KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x719a0844, ip 0x143481c, write 0, user 1, thread 0x4562 KERN: vm_page_fault: thread "(add-on)ntp_update_time" (17762) in team "CommandCenter" (602) tried to read address 0x719a0844, ip 0x143481c ("libnetwork.so_seg0ro" +0x1781c) KERN: debug_server: Thread 17762 entered the debugger: Segment violation KERN: stack trace, current PC 0x143481c nsdispatch + 0xe4: KERN: (0x71945ff8) 0x142f811 gethostbyname_internal + 0x305 KERN: (0x71946048) 0x142f4a9 gethostbyname + 0x79 KERN: (0x71946078) 0x5cf11c ntp_update_time__FPCcPPCcPl + 0x24 KERN: (0x71946188) 0x1903f04 thread_func__25NetworktimeprefletAsAddonPv + 0x290 KERN: (0x719462b8) 0x20d3c7f thread_entry + 0x23
FWIW -- might be just a coincidence, but it ran fine when unattended through the night but crashed within a few minutes of me checking the system this morning -- I checked if CC was running fine, launched a browser, accessed sites.
Will shortly provide some sample code to make it easier to reproduce this (maybe combined with some heavier network and DNS access usage, in case there is a concurrency component involved in the bug?)
Happens during being idle couple times a day:
We've been getting forwarded .report files for CC that lack stack crawls. Did not know what to think of it until this week, when looking through their syslogs I managed to find a reference to a Debugger problem, which /might/ (I hope :-) be related and explain what is going on: maybe the .report is incomplete because Debugger has silently crashed behind the scenes while generating it ?
That particular machine seems to have several problems, including corrupted BFS index, unrelated/unexplained crashes in servers and daemons, so it could be that Debugger is another bystander to another problem, but filing a ticket just in case (there is another ticket about "shortened" .reports too IIRC)
KERN: vm_soft_fault: va 0x50007000 not covered by area in address space KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x50007a47, ip 0xe512d6, write 0, user 1, thread 0xd70 KERN: vm_page_fault: thread "worker" (3440) in team "Debugger" (3439) tried to read address 0x50007a47, ip 0xe512d6 ("libroot.so_seg0ro" +0xaf2d6) KERN: debug_server: Thread 3440 entered the debugger: Segment violation KERN: stack trace, current PC 0xe512d6 malloc__Q28BPrivate10threadHeapUl + 0x4ca: KERN: (0x719c30c8) 0xe51bd4 malloc + 0x184 KERN: (0x719c30f8) 0xcb5ec3 _Allocate__7BStringl + 0x27 KERN: (0x719c3128) 0xcb5ff9 _Clone__7BStringPCcl + 0x21 KERN: (0x719c3158) 0xcb5fb4 _Init__7BStringPCcl + 0x28 KERN: (0x719c3188) 0xcb0f12 __7BStringPCc + 0x4a KERN: (0x719c31b8) 0xfeca13 GetSymbolInfos__17DebuggerInterfacellRt11BObjectList1Z10SymbolInfo + 0xe7 KERN: (0x719c3608) 0xfe2ac1 FinishInit__14ImageDebugInfoP17DebuggerInterface + 0x4d KERN: (0x719c36a8) 0xfe5f28 LoadImageDebugInfo__13TeamDebugInfoRC9ImageInfoP13LocatableFileR26ImageDebugInfoLoadingStateRP14ImageDebugInfo + 0x1c4 KERN: (0x719c36e8) 0xffa823 Do__21LoadImageDebugInfoJob + 0x8f KERN: (0x719c3768) 0x10830ed _ProcessJobs__6Worker + 0x1f9 KERN: (0x719c37a8) 0x1082df9 _WorkerLoop__6Worker + 0x21 KERN: (0x719c37e8) 0x1082dcf _WorkerLoopEntry__6WorkerPv + 0x1f KERN: (0x719c3818) 0xdd380b thread_entry + 0x23
It was probably an application bug. I've fixed the build in https://github.com/HaikuArchives/Helios.
Installed Helios 1.6 Final.
Crashes on launch.
Debug reports attached.
There is a newer revision (1.71b2) in HaikuArchives with source files. However, it does not build (errors).
There's a newer issue that has more info than this one, closing as duplicate.
Haiku revision - 49554.
I'm getting black screen after boot when using radeon_hd with my 6470M/6520G APU
Syslog is attached
Thanks for reporting!
- Install quicklaunch-0.9.11-1-x86_gcc2.hpkg which has this change.
- Launch it
- Click Setup and Add..
- Close Setup window and then file panel
- Click Setup and Add..
Setup window will not be drawn properly.