Ros-dev

ros-dev@reactos.org

2 participants
5791 discussions

RE : Usb Fault
by James Tabor 26 Sep '06

26 Sep '06

Hi, Sylvain Petreolle wrote: > Hi James, > why dont you try the new driver ? > (drivers/usb/nt4compat/usbdriver) I guess I can try it. I moved the drivers out of the directory and the system just sit there doing nothing. Thanks, James

1 0

Usb Fault
by James Tabor 25 Sep '06

25 Sep '06

Hi! Happy to boot again! Thank you Arty and Hervé! So, USB fault with real hardware. r24264 in second stage boot. It lockup on first stage and I did not get the setup gui. (dll/win32/newdev/newdev.c:736) Installing PCI-ISA bridge (PCI\VEN_1106&DEV_3177 &SUBSYS_31771106&REV_00\1&f103bba4&11) (dll/win32/newdev/newdev.c:525) Installing driver (Generic system devices): Standard PCI to ISA bridge (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\isapnp.sys" - > L"C:\\ReactOS\\System32\\drivers\\isapnp.sys" (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/newdev/newdev.c:736) Installing USB controller (PCI\VEN_1106&DEV_3104 &SUBSYS_73401462&REV_82\1&f103bba4&70) (dll/win32/newdev/newdev.c:525) Installing driver (Generic USB devices): EHCI USB controller (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbport.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbport.sys" (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbehci.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbehci.sys" (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/rpcrt4/ndr_marshall.c:928) unhandled data type=09 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ldr/loader.c:262) Could not open module file: \SystemRoot\System32\drivers\usbehci.sys (Status 0xc0000034) (ntoskrnl/io/pnpmgr/pnpmgr.c:2371) Initialization of service usbehci failed (Status c0000034) (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/newdev/newdev.c:736) Installing USB controller (PCI\VEN_1106&DEV_3038 &SUBSYS_30381106&REV_80\1&f103bba4&50) (dll/win32/newdev/newdev.c:525) Installing driver (Generic USB devices): UHCI USB controller (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbport.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbport.sys" (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbuhci.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbuhci.sys" (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/rpcrt4/ndr_marshall.c:928) unhandled data type=09 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/usbport/usbcore.c:15) Miniport 0x81C5AB48 registered (drivers/usb/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x81C7A128, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 0: A05850B8 A05803F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 172 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 1: A0585114 A05802F0 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called. .. (drivers/usb/usbport/hub.c:1230) hub_thread startingEntered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0xCDCDCDF1 could not be read: Page not present. kdb:> bt Eip: <usbuhci.sys:65b4 (drivers/usb/miniport/common/pdo.c:132 (UsbMpPdoPnp))> Frames: <usbuhci.sys:5ac2 (drivers/usb/miniport/common/main.c:402 (DispatchPnp))> <ntoskrnl.exe:3630a (ntoskrnl/io/iomgr/irp.c:1084 (IofCallDriver))> <ntoskrnl.exe:3b906 (ntoskrnl/io/pnpmgr/pnpmgr.c:944 (IopInitiatePnpIrp))> <ntoskrnl.exe:3c3c0 (ntoskrnl/io/pnpmgr/pnpmgr.c:1753 (IopActionInterrogateDeviceStack))> <ntoskrnl.exe:3c0e2 (ntoskrnl/io/pnpmgr/pnpmgr.c:972 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:3c0f7 (ntoskrnl/io/pnpmgr/pnpmgr.c:986 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:3c119 (ntoskrnl/io/pnpmgr/pnpmgr.c:1011 (IopTraverseDeviceTree))> <ntoskrnl.exe:3d822 (ntoskrnl/io/pnpmgr/pnpmgr.c:2542 (IopInvalidateDeviceRelations))> <ntoskrnl.exe:35a75 (ntoskrnl/io/iomgr/iowork.c:30 (IopWorkItemCallback))> <ntoskrnl.exe:22f38 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))> <ntoskrnl.exe:69bbc (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))> <ntoskrnl.exe:73ad2 (ntoskrnl/ke/i386/ctxswitch.S:258 (KiThreadStartup@156))> kdb:>

2 3

Mailserver and website migration over
by Aleksey Bragin 24 Sep '06

24 Sep '06

Hello, The ReactOS server is finally fully migrated now, including mailing lists, webserver with all its contents, SVN server, etc. Thanks for your patience during the server movement, we had to change really a lot of stuff, to make future transfers easier, to prevent "slashdotting" and many many other things. I am very pleased to announce that now everything is in place and is expected to work as it always did. There is a note however, for translators and admins, the static webpages are cached now and are automatically updated every 2 hours. So a change in the static web page can take as much as 2 hours before it goes "live". With the best regards, Aleksey Bragin. P.S. That spammer in ros-dev is unsubscribed from the list.

2 1

Re: [ros-dev] Contato na Syxt
by Alex Ionescu 24 Sep '06

24 Sep '06

Samuel serapion wrote: > looks like spam... from what little i understand of it > Please have the decency not to re-include the entire 10KB html email and to add your own 6KB 1-line reply. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

1 0

reactos can't boot in vmware 4.5, please fix asap
by Saveliy Tretiakov 05 Sep '06

05 Sep '06

Recent revisions can't boot in vmware 4.5. I tested some other revisions: 23800 - same problem, 23520 - boots for me. Debug log: (ntoskrnl\kd\kdio.c:193) --------------------------------------------------------------- (ntoskrnl\kd\kdio.c:194) ReactOS 0.4-SVN (Build 20060902-r23887) Used memory 131072Kb (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (lib\cmlib\hiveinit.c:154) ChunkSize: e000 (ntoskrnl\cm\import.c:73) Adding new hive (lib\cmlib\hiveinit.c:154) ChunkSize: 4000 (ntoskrnl\cm\import.c:73) Adding new hive (ntoskrnl\vdm\vdmmain.c:42) VME detected but not yet supported (0,8D3DAA90,36) (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ldr\loader.c:267) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (Status 0xc0000034) (ntoskrnl\ldr\loader.c:267) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (Status 0xc0000034) (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\io\iomgr\device.c:347) You are seeing this because the following ROS driver: \Driver\cdfs sucks. Please fix it's AddDevice Routine (./base/system/smss/initwkdll.c:70) NtOpenFile() failed (Status c000000e) (ntoskrnl\io\iomgr\device.c:347) You are seeing this because the following ROS driver: \Driver\cdfs sucks. Please fix it's AddDevice Routine (./base/system/smss/initwkdll.c:70) NtOpenFile() failed (Status c000000e) (lib\cmlib\hiveinit.c:154) ChunkSize: 20000 (lib\cmlib\hiveinit.c:154) ChunkSize: 2000 (lib\cmlib\hiveinit.c:154) ChunkSize: 2000 (lib\cmlib\hiveinit.c:154) ChunkSize: 3000 (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! *** Fatal System Error: 0x0000001e (0xC0000005,0x8001AE2C,0x00000000,0x0000000E) <ntoskrnl.exe:2518 (ntoskrnl/ke/bug.c:1069 (KeBugCheckEx))> <ntoskrnl.exe:6e5c7 (ntoskrnl/ke/i386/exp.c:790 (KiDispatchException))> <ntoskrnl.exe:76af6 (ntoskrnl/mm/i386/pfault.c:133 (KiPageFaultHandler))> <ntoskrnl.exe:71354 (ntoskrnl\ke\i386\trap.s:1412 (KiTrap14))> <ntoskrnl.exe:1ae2c (ntoskrnl/ex/resource.c:2253 (ExTryToAcquireResourceExclusiveLite))> <ntoskrnl.exe:a7cd (ntoskrnl/cc/view.c:254 (CcRosFlushDirtyPages))> <ntoskrnl.exe:4581d (ntoskrnl/mm/mpw.c:92 (MmMpwThreadMain))> <ntoskrnl.exe:63ed7 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))>

3 5

win32k coding standart
by Saveliy Tretiakov 04 Sep '06

04 Sep '06

Hi. I have two questions: 1) Do we still use DECLARE_RETURN\CLEANUP macros, or it is obsolete and shouldn't be used any more? Why not use goto directly? 2) Do we still use MmCopyFromCaller\MmCopyToCaller or not? (I heared the new standart is to use probing macros and SEH )

1 0

Re: [ros-dev] Command line
by Thomas Weidenmueller 04 Sep '06

04 Sep '06

> "Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any part in a format or chkdsk operation - they directly read and write raw clusters on the drive." That's why you have to unmount the drive when ie. formatting or chkdsk'ing it. Defragmentation however can be done whithout unmounting, because the fs driver handles this job. The IOCTLs are documented in the platform sdk, defragmentation really doesn't work using fmifs/ufat/untfs/u... - Thomas

1 0

Re: [ros-dev] Command line
by Imre Leber 04 Sep '06

04 Sep '06

>From the sysinternals website that is somewhat involved with microsoft: "Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any part in a format or chkdsk operation - they directly read and write raw clusters on the drive." Imre >-----Original Message----- >From: Thomas Weidenmueller [mailto:w3seek@reactos.com] >Sent: Monday, September 4, 2006 03:42 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > > >> The big benefit of using this library is that it let's you write code to >> manipulate the FAT file system that works on FAT12, FAT16, FAT32 without >> knowing the exact FAT file system this is going to run on. The same code >> works for FAT12, FAT16, FAT32 without having code that looks like: > >In ROS each FS driver has to implement the defrag APIs. An application can >defrag any FS by using the 3 publicly documented IOCTLs. >UFAT/UNTFS/Uxxx... is not used for fs defragmentation. > >> Anyway this could be used as the basis for ufat.dll. The utilities that >> already use this library could then also be put in here. And the rest can >> then be easily written. > >As mentioned above, defragmentation is done by the fs drivers in kernel mode. > >> What would then be needed is the actual functions that make up the >> interface to ufat.dll. > >We can design the interfaces to ufat, untfs, ... as we wish. These >interfaces are not documented publicly as there is no standard. each FS >should come with it's own utilities. Chkdsk can only be used with the file >systems that come with windows/reactos, other FS need to provide their own >tools. > >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] Command line
by Imre Leber 04 Sep '06

04 Sep '06

The current design of defrag, chkdsk, recover FAT manipulation utilities in FreeDOS is that there is a FAT manipulation library called the "FAT transformation engine" that all the other utilities use. The big benefit of using this library is that it let's you write code to manipulate the FAT file system that works on FAT12, FAT16, FAT32 without knowing the exact FAT file system this is going to run on. The same code works for FAT12, FAT16, FAT32 without having code that looks like: if it is FAT12 do this, and if it is FAT16 do that and if it is FAT32 do again something else. Like is done in the reactos loader (freeloader?) This is optimized code that is used in real life programs. Anyway this could be used as the basis for ufat.dll. The utilities that already use this library could then also be put in here. And the rest can then be easily written. What would then be needed is the actual functions that make up the interface to ufat.dll. I've seen that there is example code on the internet that uses these functions. On http://www.sysinternals.com/SourceCode/fmifs.html Imre >-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Monday, September 4, 2006 02:23 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > >On 9/3/06, Aleksey Bragin <aleksey(a)studiocerebral.com> wrote: >> We are really in demand of a working check-disk utility, so I gladly >> accept any correctly working version compatible with Windows (as in: >> not depending on specific ReactOS's features). >> It doesn't stop us from implementing fmifs.dll, uFILESYSTEM.dll's, >> etc too. Even helps, I would say. > >Thats why I started porting the dosfsck a while back. Some of the >lower level dlls for filesystem checking are highly obfuscated. It >would be better to have a working tool now rather than never. > > >-- >Steven Edwards > >"There is one thing stronger than all the armies in the world, and >that is an idea whose time has come." - Victor Hugo >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

2 1

Re: [ros-dev] War Continues?
by Thomas Weidenmueller 04 Sep '06

04 Sep '06

> This needs to end, now! *WE* would have to do something, not them. The credibility is quite low, which is absolutely comprehensible. But that's not neccessary because I believe it's already too late. I don't think the relationship to wine is ever going to be the one it used to be again. Let's just live with it... - Thomas

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev